Week 3: Using OpenSSL...

...to create signed certificates without the private key!

While dying of confusion from looking at OpenSSL code, I stumbled upon something interesting. The function that checks the private keys of the CA Certificate file and the CA key file actually just checks the public keys. Because of this, it should be possible to use OpenSSL's utilities to create a signed certificate using just the CA Certificate PEM file: Modify the base64 encoding of the CA Certificate PEM file to use the same public key as any random CA key file. (Alternatively, one could modify their CA key file to have the same public key as the CA Certificate PEM file.) This seems like it would work with the UM Web CA Certificate. However, I don't think something like this would work with something root-certified such as the InCommon CA.

For more clarity, on a standard self-signing process, several files are involved:

• CA/Root Private Key file - rootCA.key
• CA/Root Certificate file - rootCA.pem
• Certificate Serial number file - rootCA.srl 
• Certificate Request file - newcsr.pem
• Signed Certificate file - newcert.pem

Private keys and root certificates have matching public keys in their PEM encoding, so programs like OpenSSL can verify that the certificate file's modulus and exponent match the private key's. Then, someone (possibly yourself) generates a certificate request and saves it into a file. Various details go into this, such as  Country Name, Locality Name, Organization Name, Common Name, and email. I looked into the code that corresponded to the generation of certificate requests, and luckily, one cannot use a buffer overflow attack to wreck havoc on any online server that creates certificates using openSSL's latest version. Finally, the PEM formats for the CA Certificate file match the format for the Signed Certificate file. 

The PEM format, is, alas, a bit complex. For RSA key files, you have some header information followed by the modulus, public exponent, private exponent, p, and q. This is simple compared to the PEM formats for Certificate Request and Root/Signed Certificate files. They have headers (whose meaning has to be looked up on old documentation websites), followed by all the subject info (Country Name, State Name, etc.) interlaced with even more header information. At some point, the PEM file format describes the encryption info (like 1024 bit RSA Encryption), followed by the modulus, exponent, certificate attributes, and signature algorithm (like sha1WithRSAEncryption). 

Converting to and from base64 to hex takes a bit of effort as well. What we have is actually several lines of 64-character "words." Each line uniquely translates to a 384-bit word. But you might have part of a modulus beginning on the middle of a line and ending in the middle of another line. In order to modify this, special precautions have to be kept. Conversions from hex to base64 don't make sense unless it's a 384-bit (or 96 hex characters, where 0x41 is 2 hex characters) word. Because of this, one would have to find every affected line by a change, modify their hex values, and then convert each line individually from hex to base64. 

OpenSSL is notoriously difficult to read through. There's very little documentation, and function calls literally go everywhere- they jump around different source files in different folders. The certificate signing is done in the apps/x509.c file, whose simple sign function actually has its tree of function calls going to perhaps at least 25 other *.c files, such as crypto/x509/x509_vfy.c, and referencing files like /include/openssl/x509.h. 

I'm also trying to envision the Gnocchi top level structure while I'm at it. I really don't like sifting through OpenSSL code, which I chose to do because I wasn't familiar with the server/javascript involved with the Gnocchi development side. We still have to figure out a good key revocation scheme, meaning our idea of having 4 key portions-- Publisher, High-Bandwidth Content Server, Client, and Low-Bandwidth Key Server-- is not set in stone.

I talked to the guys at ITS, and it looks like we're getting a chance to see how their certificate approval works!