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