It is a PEM....sort of
Adam Young
ayoung at redhat.com
Fri Mar 19 02:13:24 UTC 2010
So here is the issue with our PEMs, AFAICT:
I changed the code in
DefaultIdentityCertServiceAdapter.createIdentityCert to use the
Bouncycastle PEMWriter. If you look into the Byte buffer, the correct
ascii values are there. It is still there when the getPem call happens
as part of the read Consumer. Unfortunately, I can't trace beyond this
method, as it disappears into a bunch of com.sun classes from the JDKs
rt.jar, whcih I suspect are native code. THe .java files fro them are
not distributed with any of the JDK RPMs in Fedora 12.
Tee byte arra starts with a series of ascii - which is code 45.
I suspected that what is happing is that the byte array is not being
treated as ascii, but instead as utf-16, when the marshalling converts
from byte array. However, if we look at the final product, we should
expect to see some thing repetitive due to two 45s being treated as a
singe character. But what we see in hexdump is nothing like that
000001d0 77 58 77 49 44 41 51 41 42 22 2c 22 70 65 6d 22
|wXwIDAQAB","pem"|
000001e0 3a 22 4c 53 30 74 4c 53 31 43 52 55 64 4a 54 69
|:"LS0tLS1CRUdJTi|
THe next place up the stack where I can inspect the values is
BaseMarshaller.marshal(Object o, OutputStream outputStream)
If I look inside the output stream there I see the same values that I
see in the end cert. So JAX Marshalling is failing to handle the PEM.
Don't know why.
One thing I can try is to, character by character, convert the PEM to a
java String.
More information about the candlepin
mailing list