s_client nicht bei widerrufenem Zertifikat fehlgeschlagen?

3240
jww

Ich verwende Firefox mit HTTPS Everywhere der EFF . Ich habe kürzlich die Website von Lavabit besucht, um zu sehen, ob sie Spenden akzeptiert:

enter image description here

Der Widerruf wird unter Berücksichtigung der Geschichte erwartet.

Ich dupliziere das Ergebnis jedoch nicht mit OpenSSLs s_client. Unten bekomme ich Verify return code: 3 (unable to get certificate CRL)was X509_V_ERR_UNABLE_TO_GET_CRL, anstatt X509_V_ERR_CERT_REVOKED: certificate revoked. Der Befehl lautet:

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

Die CA-Datei befindet sich bei 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

Das Zertifikat des Servers scheint auf eine gültige CRL zu verweisen.

Irgendwelche Ideen, was ich falsch machen könnte?

4
Dieser zweite Widerruf ist auf Heartbleed zurückzuführen, obwohl ich schwöre, dass die Ersatzzertifizierung vollkommene Geheimhaltung unterstützt. Ich habe an diesem Punkt nichts mit OpenSSL vertraut Ramhound vor 10 Jahren 0
Das Zertifikat hat nichts mit PFS zu tun. PFS verwendet statt RSA nur einen DHE- oder ECDHE-Schlüsselaustausch. Ich würde keinem der TLS-Stacks (alle großen hatten in der Vergangenheit gravierende Probleme) und auch nicht der aktuellen PKI-Architektur vertrauen. Steffen Ullrich vor 10 Jahren 0

2 Antworten auf die Frage

8
Steffen Ullrich

Wenn die Probleme von openssl ihre schlechte Dokumentation und arkane Verwendung sind. Selbst mit dieser Option -crl_checkwerden keine OCSP-Prüfungen oder Download-CRLs durchgeführt, und Sie können so etwas wie -CRLfilebei s_client nicht verwenden. Sie müssen stattdessen die CRLs und die Zertifizierungsstelle in derselben Datei speichern (durch einen Blick auf den Quellcode, der tatsächlich lesbar ist).

Da es so aussieht, als hätten Sie die Zertifizierungsstelle bereits im PEM-Format valicert_class2_root.crt, können Sie die CRLs folgendermaßen hinzufügen:

  • Rufen Sie die CRLs von der http://crl.godaddy.com/gds1-64.crlim Zertifikat angegebenen URL mit wget oder ähnlichem ab
  • Da die CRLs, die Sie erhalten haben, im DER-Format vorliegen, müssen Sie sie in PEM konvertieren openssl crl -in gds1-64.crl -inform der -out crl.pem
  • das Anhängen crl.peman Ihre CA-Datei

Wenn Sie den gleichen s_clientBefehl erneut versuchen, erhalten SieVerify return code: 23 (certificate revoked)

Oh, ich wusste nicht, dass -crl_check die CRL nicht abgerufen hat. jww vor 10 Jahren 0
Es ist nicht dokumentiert, dass dies der Fall ist - und kein Dokument, dass dies nicht der Fall ist. Eigentlich ist überhaupt nicht dokumentiert, was es wirklich tut :( Steffen Ullrich vor 10 Jahren 0
Können Sie einen [OpenSSL / RT-Fehlerbericht] (https://www.openssl.org/docs/faq.html#BUILD17) für Dokumentationsprobleme aufarbeiten? Sie können auf diese Frage verweisen, wenn Sie möchten. jww vor 8 Jahren 0
@ jww: Ich denke, das wäre Zeitverschwendung. Es gibt schon so viele falsche oder fehlende Dokumentation mit openssl und ich kann nicht wirklich erkennen, dass sie sich so wichtig fühlen, Steffen Ullrich vor 8 Jahren 0
In der Vergangenheit war das definitiv Zeitverschwendung (das spricht aus Erfahrung). Die Dinge haben sich in den letzten Jahren geändert, und die Dokumentation ist eine der einfacheren Anforderungen (dies spricht auch aus Erfahrung). Die Änderungen erfolgten nach Heartbleed, dem Katalysator für die erstklassige Finanzierung des Projekts von Unternehmen und der Linux Foundation. Sie sollten es in Erwägung ziehen, es noch einmal zu versuchen. jww vor 8 Jahren 0
@ jww: Du kannst das Problem gerne selbst einreichen und ich wünsche dir viel Erfolg. Als Hilfe: Die entsprechende Option ist in `apps / apps.h` definiert und wird in` apps / opt.c` verwendet. Alles was sie tut, ist `X509_V_FLAG_CRL_CHECK`. Und während in "./doc/crypto/X509_VERIFY_PARAM_set_flags.pod" dokumentiert wird, dass diese Option vorhanden ist und "die CRL-Überprüfung für das Zertifikatskettenblatt aktiviert wird", gibt es keine Informationen darüber, wie diese CRL-Prüfung genau abgesehen von "Wenn CRLs ausgeführt wird Es wird erwartet, dass CRLs in der entsprechenden X509_STORE-Struktur verfügbar sind. Es wird nicht versucht, CRLs herunterzuladen ... " Steffen Ullrich vor 8 Jahren 0
2
robbat2

Steffan schlug mich auf die Antwort, als ich nachforschte.

Seine Antwort funktioniert am besten für schnelles Zeug. Wenn Sie stattdessen CApath verwenden möchten, müssen Sie sicherstellen, dass die Dateinamen korrekt gehashed sind ($ HASH.r0), was in openssl völlig undokumentiert ist. Sie sollten sicherstellen, dass Sie ALLE CRLs an die Datei anhängen, wenn Sie diese Methode verwenden, nicht nur die CRL für das erste Zertifikat.

Es gibt einige Tools, mit denen Sie CRLs abrufen können, um Ihr System aufzufüllen: http://wiki.nikhef.nl/grid/FetchCRL3

Vielen Dank Robbat2. Ich benutze niemals "CAPath", da ich generell den CA Zoo meide. Danke für das Tool. jww vor 10 Jahren 0
Können Sie einen [OpenSSL / RT-Fehlerbericht] (https://www.openssl.org/docs/faq.html#BUILD17) für Dokumentationsprobleme aufarbeiten? Sie können auf diese Frage verweisen, wenn Sie möchten. jww vor 8 Jahren 0
@jww Ich habe es einige Monate nach meinem Posting behoben. Es liegt jetzt in der [Dokumentation für `c_rehash`] (https://github.com/openssl/openssl/commit/cf2239b3b397174a8a6b1cc84ff68aba34ed5941) robbat2 vor 8 Jahren 0

Verwandte Probleme