Question s_client ne pas échouer sur le certifcate révoqué?


J'utilise Firefox avec les EFF HTTPS partout. J'ai récemment visité le site de Lavabit pour voir si ses dons acceptaient:

enter image description here

La révocation est attendue compte tenu de l'histoire ....

Cependant, je ne duplique pas le résultat en utilisant OpenSSL s_client. Ci-dessous, je reçois Verify return code: 3 (unable to get certificate CRL) lequel est X509_V_ERR_UNABLE_TO_GET_CRL, plutôt que X509_V_ERR_CERT_REVOKED: certificate revoked. La commande est la suivante:

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

Le fichier CA peut être trouvé à Chaîne de certificats ValiCert existante.

$ 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

Le certificat du serveur apparaît pour pointer vers une liste de révocation de certificats valide.

Des idées que je fais peut-être mal?


4
2018-04-16 00:42


origine


Cette deuxième révocation est due à Heartbleed, même si je jure que la certification de remplacement prend en charge le secret parfait. Je ne fais pas confiance à OpenSSL à ce stade - Ramhound
Le certificat n'a rien à voir avec PFS. PFS utilise simplement un échange de clés DHE ou ECDHE au lieu de RSA. Et je ne ferais confiance à aucune des piles TLS (toutes les principales avaient des problèmes graves dans le passé) et je ne ferais pas confiance à l'architecture PKI actuelle. - Steffen Ullrich


Réponses:


Un si les problèmes de openssl sont leur mauvaise documentation et l'utilisation d'arcane. Même avec option -crl_check il ne fera pas de vérification OCSP ou télécharger des listes de révocation de certificats, et vous ne pouvez pas utiliser quelque chose comme -CRLfile avec s_client. Ce que vous devez faire à la place, c’est d’avoir les listes de révocation de certificats et l’autorité de certification dans le même fichier (trouvé en consultant le code source, qui est en fait lisible).

Comme il semble que l’AC soit déjà au format PEM dans valicert_class2_root.crt vous pouvez faire ce qui suit pour ajouter les CRL aussi:

  • obtenir les CRL à partir de l'URL http://crl.godaddy.com/gds1-64.crl donné dans le certificat en utilisant wget ou similaire
  • parce que les CRL que vous avez sont au format DER, vous devez les convertir en PEM avec openssl crl -in gds1-64.crl -inform der -out crl.pem
  • l'ajout crl.pem dans votre fichier CA

Si vous réessayez le même s_client commande vous obtenez Verify return code: 23 (certificate revoked)


8
2018-04-16 05:48



Oh, je ne savais pas -crl_check n'a pas récupéré la CRL. - jww
Il n'est pas documenté que c'est le cas - et non documenté que ce n'est pas le cas. En fait, il n'est pas documenté du tout ce qu'il fait vraiment :( - Steffen Ullrich
Pouvez-vous travailler un Rapport de bogue OpenSSL / RT pour les problèmes de documentation? Vous pouvez référencer cette question, si vous le souhaitez. - jww
@jww: Je pense que ce serait une perte de temps. Il y a déjà tellement de documentation erronée ou manquante avec openssl et je ne peux pas vraiment voir qu'ils sentent ce genre de choses suffisamment important pour être corrigé, - Steffen Ullrich
Dans le passé, c'était définitivement une perte de temps (cela parle de l'expérience). Les choses ont changé au cours des deux dernières années, et la documentation est l’une des demandes les plus faciles à formuler (c’est aussi une question d’expérience). Les changements sont intervenus après Heartbleed, qui a été le catalyseur du financement de première classe du projet par les entreprises et la Linux Foundation. Vous devriez envisager de faire un autre essai. - jww


Steffan m'a battu à la réponse pendant que je cherchais.

Sa réponse fonctionne mieux pour les choses rapides. Si vous souhaitez utiliser CApath à la place, vous devez vous assurer que les noms de fichiers sont correctement hachés ($ HASH.r0), ce qui n'est pas documenté dans openssl. Vous devez vous assurer que vous ajoutez toutes les listes de révocation de certificats au fichier si vous utilisez cette méthode, pas seulement la liste de révocation de certificats pour le premier certificat.

Certains outils peuvent récupérer des listes de révocation de certificats pour remplir votre système: http://wiki.nikhef.nl/grid/FetchCRL3


2
2018-04-16 06:53



Merci Robbat2. Je n'utilise jamais CAPath puisque j'évite généralement le zoo de CA. Merci pour l'outil. - jww
Pouvez-vous travailler un Rapport de bogue OpenSSL / RT pour les problèmes de documentation? Vous pouvez référencer cette question, si vous le souhaitez. - jww
@jww je l'ai fait réparer quelques mois après mon affectation. Il se trouve maintenant dans la documentation pour c_rehash - robbat2