s_client not failing on revoked certifcate?

4

I'm running Firefox with with the EFF's HTTPS Everywhere. I recently visited Lavabit's site to see if its accepting donations:

enter image description here

The revocation is expected considering the history....

However, I'm not duplicating the result using OpenSSL's s_client. Below, I'm getting Verify return code: 3 (unable to get certificate CRL) which is X509_V_ERR_UNABLE_TO_GET_CRL, rather than X509_V_ERR_CERT_REVOKED: certificate revoked. The command is:

openssl s_client -connect lavabit.com:443 -crl_check -CAfile valicert_class2_root.crt

The CA file can be found at ValiCert Legacy Certificate Chain.

$ echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect lavabit.com:443 -crl_check -CAfile valicert_class2_root.crt 
CONNECTED(00000003)
depth=0 O = *.lavabit.com, OU = Domain Control Validated, CN = *.lavabit.com
verify error:num=3:unable to get certificate CRL
verify return:1
depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert Class 2 Policy Validation Authority, CN = http://www.valicert.com/, emailAddress = info@valicert.com
verify return:1
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify return:1
depth=0 O = *.lavabit.com, OU = Domain Control Validated, CN = *.lavabit.com
verify return:1
---
Certificate chain
 0 s:/O=*.lavabit.com/OU=Domain Control Validated/CN=*.lavabit.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
 3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFWTCCBEGgAwIBAgIHJ3H9XXOouzANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTIwMjE3MDQwNzQ2WhcNMTcwMjE3MDQwNzQ2WjBTMRYwFAYDVQQKDA0q
LmxhdmFiaXQuY29tMSEwHwYDVQQLDBhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQx
FjAUBgNVBAMMDSoubGF2YWJpdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDPMNYGqnkvQBSlaen/VYxIdA57nANIYAAY4Nkt148BDgHdcgNJjjH7
YI9EM0hPRXF8lvU9F+dA0ejaxYz0KQMxzXS+uvfv2nPS97+HI3qlD9Tr4MsJRS2c
5TzUNQ03CxC9QCpMywwQJ/9KBCALCAjzlNalWCf1U2Vb7Q9+YKUa9YlPnVpOudSH
Z6H7y3+hAydrP/Wq6H8KP29xlExj8KNzY3EqVRqJvLQ+oVre4bqPO4FdWsSOGVGr
oMEXBTZewkefAN8PBk3lJ4ka/SLgiQtxnw2aNkKM2zw/wzPZU2Ri+J7sdCBd2aKy
YnfTn59ZELu5Kv/JdzARCcYMJ1GSI95pAgMBAAGjggG4MIIBtDAPBgNVHRMBAf8E
BTADAQEAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8E
BAMCBaAwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nb2RhZGR5LmNvbS9n
ZHMxLTY0LmNybDBTBgNVHSAETDBKMEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYBBQUH
AgEWK2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS8w
gYAGCCsGAQUFBwEBBHQwcjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRk
eS5jb20vMEoGCCsGAQUFBzAChj5odHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHku
Y29tL3JlcG9zaXRvcnkvZ2RfaW50ZXJtZWRpYXRlLmNydDAfBgNVHSMEGDAWgBT9
rGEyk2xF1uLuhV+auud2mWjM5zAlBgNVHREEHjAcgg0qLmxhdmFiaXQuY29tggts
YXZhYml0LmNvbTAdBgNVHQ4EFgQU8/u0eeUoWQaMfxTlv9NohxLD0dMwDQYJKoZI
hvcNAQEFBQADggEBAAUIImu3UtjasUc9ACCaoobHUWxU3SS1KQfGvt77NKIjzAuR
65H3lR7wQcVi4Ke4C/OXgyq4md5Q9W7s3IlbW++MdtFhzM8WG6yuI66C3zHG+DP4
qov8X7ckqrRU50cE1CAh/HZHIvGRYqKVjdxI/8ReX6DS6C8NaDHXaLsO/aClKuxQ
3J5WsqipUKsbhoDj6Z18yRFmdCks2+ySNPEF6YIz5/hYyPipeyWUqY8FIFSqmm0E
NHhiBp2s/3gROk2bIg1qxlNFnSRTttLQg6wEX8CGQ9EsTcqNk3LsdknZXlTQ7JCN
hK7okkwwXgUdFUkWZQej9XhWFAqkbCvC9hVI1Aw=
-----END CERTIFICATE-----
subject=/O=*.lavabit.com/OU=Domain Control Validated/CN=*.lavabit.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 5357 bytes and written 715 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 67541EBB72FADE3B388F12AD47964AFE...
    Session-ID-ctx: 
    Master-Key: A070BD05576771DD47459ED6071807FC...
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1397614017
    Timeout   : 300 (sec)
Verify return code: 3 (unable to get certificate CRL)
---
DONE

The server's certificate appears to point to a valid CRL.

Any ideas what I might be doing wrong?

jww

Posted 2014-04-16T00:42:51.160

Reputation: 1

This second revocation is because of Heartbleed although I swear the replacement certification support perfect forward secrecy. I don't trust anything about OpenSSL at this point – Ramhound – 2014-04-16T00:46:24.310

The certificate has nothing to do with PFS. PFS is just using a DHE or ECDHE key exchange instead of RSA. And I would not trust any of the TLS stacks (all the major ones had serious issues in the past) nor would I trust the current PKI architecture. – Steffen Ullrich – 2014-04-16T05:52:13.653

Answers

8

One if the issues of openssl is their bad documentation and arcane usage. Even with option -crl_check it will not do any OCSP checks or download CRLs, nor can you use something like -CRLfile with s_client. What you instead need to do is to have the CRLs and the CA in the same file (found it by looking at the source code, which is actually readable).

Since it looks like that you have the CA already in PEM format in valicert_class2_root.crt you can do the following to add the CRLs too it:

  • get the CRLs from the URL http://crl.godaddy.com/gds1-64.crl given in the certificate using wget or similar
  • because the CRLs you got are in DER format you need to convert them to PEM with openssl crl -in gds1-64.crl -inform der -out crl.pem
  • the append crl.pem to your CA file

If you the retry the same s_client command you get Verify return code: 23 (certificate revoked)

Steffen Ullrich

Posted 2014-04-16T00:42:51.160

Reputation: 3 897

Can you work up a OpenSSL/RT bug report for the documentation problems? You can reference this question, if you'd like.

– jww – 2016-03-31T19:06:48.207

@jww: I think that would be a waste of time. There is so much wrong or missing documentation with openssl already and I cannot really see that they feel such stuff important enough to fix, – Steffen Ullrich – 2016-03-31T19:09:25.313

In the past, it was definitely a waste of time (that's speaking from experience). Things have changed in the past couple of years, and documentation is one of the easier requests to make (that's also speaking from experience). The changes came after Heartbleed, which was the catalyst for first class funding of the project from corporations and the Linux Foundation. You should consider giving it another try. – jww – 2016-03-31T19:25:01.197

@jww: you are welcome to file the issue yourself and I wish you success. As a help: The relevant option is defined in apps/apps.h and used in apps/opt.c and all what it does is set X509_V_FLAG_CRL_CHECK. And while it is document in ./doc/crypto/X509_VERIFY_PARAM_set_flags.pod that this option exists and that it "enables CRL checking for the certificate chain leaf" there are no information how this CRL checking is done exactly apart from "If CRLs checking is enable CRLs are expected to be available in the corresponding X509_STORE structure. No attempt is made to download CRLs..." – Steffen Ullrich – 2016-03-31T19:38:53.970

Oh, I did not know -crl_check did not fetch the CRL. – jww – 2014-04-16T13:49:52.137

It is not documented that it does - and no documented that it does not. Actually it is not documented at all what it really does :( – Steffen Ullrich – 2014-04-16T17:12:19.313

2

Steffan beat me to the answer while I was researching it.

His answer works best for quick stuff. If you want to use CApath instead, you need to make sure that the filenames are correctly hashed ($HASH.r0), which is entirely undocumented in openssl. You should make sure that you append ALL of the CRLs to the file if you are using that method, not just the CRL for the first cert.

There are some tools that can fetch CRLs to populate your system: http://wiki.nikhef.nl/grid/FetchCRL3

robbat2

Posted 2014-04-16T00:42:51.160

Reputation: 821

Can you work up a OpenSSL/RT bug report for the documentation problems? You can reference this question, if you'd like.

– jww – 2016-03-31T19:07:26.847

@jww I got it fixed a few months after my posting. It now lies in the documentation for c_rehash

– robbat2 – 2016-03-31T21:13:19.507

Thanks Robbat2. I never use CAPath since I generally avoid the CA Zoo. Thanks for the tool. – jww – 2014-04-16T13:51:16.480