0

Here's the scenario.

  • Server: Ubuntu 12.04 -- postfix and dovecot
  • Client: Ubuntu 13.10 -- offlineimap and msmtp

I'm finishing off my recovery from Heartbleed and want to re-issue my own server certificate. Since it is a private server, I originally created a CA, then used the CA to sign the server certificate. The CA cert is properly installed on my client system, the server key and cert are installed on the server.

Now, I have created a CRL and divined that the CRL need not go on the server (except to distribute far and wide if I had any other users), but does need to be installed on my desktop machine so that OpenSSL won't accept the original key. So, I copied the CRL file into /etc/ssl/crl. I created the link using

ln -s mycrl.pem `openssl crl -hash -noout -in mycrl.pem`.0

The result of that looks reasonable.

openssl s_client connections to the server just fine. No error messages that I can see in the connection, but I expect there to be all kinds of errors and possibly even a refusal to connect. So, I look in my openssl configuration file and move the CRL file to /etc/ssl/crl.pem. Same result:

depth=1 C = US, ST = TX, L = Austin, O = SavanniDGerinel, OU = SavanniDGerinel, CN = SavanniDGerinel CA, name = savannidgerinel.com, emailAddress = savanni@alyra.org
verify return:1
depth=0 C = US, ST = TX, L = Austin, O = SavanniDGerinel, OU = SavanniDGerinel, CN = apps.savannidgerinel.com, name = savannidgerinel.com, emailAddress = savanni@alyra.org
verify return:1
---
Certificate chain
 0 s:/C=US/ST=TX/L=Austin/O=SavanniDGerinel/OU=SavanniDGerinel/CN=apps.savannidgerinel.com/name=savannidgerinel.com/emailAddress=savanni@alyra.org
   i:/C=US/ST=TX/L=Austin/O=SavanniDGerinel/OU=SavanniDGerinel/CN=SavanniDGerinel CA/name=savannidgerinel.com/emailAddress=savanni@alyra.org
... tons more stuff ....
SSL-Session:
  ... tons of sessions stuff ...
  Verify return code: 0 (ok)

How do I force the OpenSSL system on my laptop to actually pay attention to revocation files? And, given that I'm sure that certificates get revoked regularly, why are there absolutely no other CRL files on my system? How can I be sure that I'm actually connecting to what I think I'm connecting to?

Not to put too fine a point on it, but why is installing a revocation list difficult? This strikes me as the kind of thing that has to be trivial for end users who know nothing in order to ensure internet security.

2

To use OpenSSL s_client with CRL verification you have to do various undocumented things, which I've described in https://superuser.com/questions/742231/s-client-not-failing-on-revoked-certifcate/742289#742289.

Apart from that I don't know if any application using OpenSSL does CRL checks at all, because I think you have to explicitly enable these checks in the API and then put the CRL at unexpected places. And of course there is no automatic downloading of CRLs.

If you think now that all this TLS stuff is broken you are probably right and this does not apply only to OpenSSL.

  • So... basically there is no way to prevent a man-in-the-middle attack, because I can't ever get an application to reject my old potentially compromised key? – Savanni D'Gerinel Apr 17 '14 at 15:00
  • There are API functions to use CRLs and there is also OCSP support. But the download of the CRL must be done by the application, because OpenSSL is just a library not a user agent which knows about proxies, authentication and all the web stuff. OpenSSL has also support for OCSP (unfortunately undocumented), but the s_client tool (which is only intended for testing) has no support for it. In summary - there is support for CRL checking, but the application using OpenSSL has to deal with the necessary details itself. Some might do, others don't. – Steffen Ullrich Apr 17 '14 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.