Week 4: OpenSSL part 3

In order to test potential exploits I thought of, I setup a private web server using an old computer box. It was my first time doing so, and I learned a bit about routers, networking, ports... (which unfortunately is not the topic of this blog post).

OpenSSL's verify utility can be used to verify certificate chains. In order to do this, one would have to concatenate the chain of certificates into one file, from root-level first. For example, umich was signed by InCommon, which was signed by AdTrust, a root-level Certificate Authority. To have OpenSSL verify it, one would use the commands:

cat adtrust.crt incom.crt umich.crt > combinedCerts.crt
openssl verify -CAfile adtrust.crt combinedCerts.crt

Here, -CAfile specifies a trusted root certificate.

I tried to step through the process of making a fake certificate.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -in server.csr -CA incom.crt -CAkey server.key -CAcreateserial -out fake.crt -days 500

Unfortunately, the 3rd command failed because the "private key didn't match the certificate," when the error in OpenSSL was caused by the mismatch in public keys. (Now that I think about it, I was probably misinterpreting private key to mean the (m,d) pair rather than the server.key file.)  To have the public keys match, I modified the first 6 base-64 lines of server.key to contain the public key of the certificate I was signing with (incom.crt). This was called fakeIC.crt. The command,

openssl x509 -req -in server.csr -CA incom.crt -CAkey fakeIC.key -CAcreateserial -out fake.crt -days 500

was ran, which succeeded without error. Verification with OpenSSL in the manner described above succeeded as well! Apparently OpenSSL's verify utility only checks to see that certificates... have the names of their signers on them? I put the certificate chain (adtrust-inCommon-fake.crt) onto the ssl portion of my web server and tried accessing the https port via Chrome. There was an error- fake.crt had an invalid digital signature.

My thoughts at this point were: Perhaps it's because I didn't use x509v3 extensions, which the umich certificate had. Or perhaps I could fake-sign with umich's certificate rather than incom's certificate.

I found out that signing certificates with v3 extensions requred a v3extensions file, which had the data to be placed in as v3 extensions. I made such a file, v3.ext, and wrote it with the same information as the v3 extension information on umich's certificate. Signing with v3 extensions, as well as signing with umich's certificate, both failed the chrome test.

At this point I figured it was because of the actual "signature" portion of the certificate being wrong (silly me). Apparently actual SSL checks the signature, unlike OpenSSL's verify.

I also found that batch requests for OpenSSL's req utility don't actually make/sign multiple certificate requests. Rather, they omit the part of openssl req where the user inputs their certificate subject/credentials via standard input. Optionally, the subject/credentials can be taken from a file. So for someone making many requests using similar subject/credentials, they might use the batch utility as well as a script, but ultimately OpenSSL does not handle requests in bulk. This was further verified by UofM ITS, who said they don't handle multiple certificate requests at the same time either.