Warum überprüft openssl s_client ein Zertifikat anhand einer nicht übereinstimmenden CA-Datei?

Ich versuche, einen Zertifikatüberprüfungsfehler openssl s_clientwie folgt zu erhalten:

$ openssl s_client -crlf -verify 9 \
  -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
  -starttls smtp -host mx-ha03.web.de -port 25

Das Zertifikat des web.de-Servers ist von der Deutschen Telekom CA zertifiziert, nicht von TURKTRUST. Daher sollte der obige Befehl fehlschlagen, oder?

Aber es berichtet:

    Verify return code: 0 (ok)

Warum?

Ich meine, ein analoger gnutls-cli-Befehl schlägt wie erwartet fehl:

$ { echo -e 'ehlo example.org\nstarttls' ; sleep 1 } | \
   gnutls-cli --starttls --crlf \
   --x509cafile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem \
   --port 25 mx-ha03.web.de
[..]
*** Verifying server certificate failed...

Wenn --x509cafile /etc/ssl/certs/ca-certificates.crtich einen Crosscheck mache, dh stattdessen mit gnutls-cli benutze, bekomme ich:

[..]
- The hostname in the certificate matches 'mx-ha03.web.de'.
- Peer's certificate is trusted

(was auch erwartet wird)

Openssl s_client druckt für ca-certificates.crt:

    Verify return code: 0 (ok)

Das gleiche Ergebnis wie für TURKTRUST ...

Zuerst vermutete ich openssl mit einer Standardeinstellung für -CApath(dh / etc / ssl / certs) - aber wenn ich straceden Prozess durchführe, sehe ich nur den openSyscall für das Argument von CAfile.

(alle Tests auf einem Ubuntu 10.04 Server durchgeführt)

Update: Ich habe das TURKTRUST-Zertifikat auf ein Fedora 20-System kopiert und die erste openssl-Anweisung ausgeführt - dort erhalte ich ein anderes Ergebnis:

Verify return code: 19 (self signed certificate in certificate chain)

Es stellt sich heraus, dass openssl s_clientunter Ubuntu 10.04 immer noch ein Standardspeicherort für vom System installierte Zertifikate abgefragt wird, selbst wenn -CApath und -CAfile angegeben sind:

8466  open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(Strace-Ausgabe)

Wo:

$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 ->
    Deutsche_Telekom_Root_CA_2.pem

Das Verzeichnis /usr/lib/ssl/certsist ein Symlink zu /etc/ssl/certsUbuntu 10.04, daher wird die openZeile aus dem Strace-Protokoll nicht ausgewählt, wenn nach '/ etc / ssl' gesucht wird ...

Quelle

Mit Blick auf die OpenSSL-0.9.8k, die Quelle dieses Problem in liegt crypto/x509/by_dir.c, dir_ctrl():

dir=(char *)Getenv(X509_get_default_cert_dir_env());
if (dir)
    ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
else
    ret=add_cert_dir(ld,X509_get_default_cert_dir(),
                     X509_FILETYPE_PEM);

Wo X509_get_default_cert_dirzurück /usr/lib/ssl/certsund X509_get_default_cert_dir_envzurück SSL_CERT_DIR.

Problemumgehung

Daher kann unter Ubuntu 10.04 / openssl 0.9.8k die folgende Problemumgehung verwendet werden, um das erwartete Verhalten zu erhalten:

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \
    -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \
    -starttls smtp -host mx-ha03.web.de -port 25

Und mit der Überprüfung schlägt fehl:

Verify return code: 19 (self signed certificate in certificate chain)

Momentane Situation

Dies ist ein Ubuntu-Problem. Beispielsweise ist diese Problemumgehung mit dem OpenSl 1.0.1e von Fedora 20 oder dem OpenSL 1.1.1 von Fedora 29 nicht erforderlich, da das Problem nicht reproduziert werden kann. Das heißt, wenn Sie eine Option wie -CAfileoder -CApathangeben, wird der Verzeichnissuchliste auf Fedora-Systemen kein Standardzertifikatsystemverzeichnis hinzugefügt.

Unter Ubuntu 16 mit openssl 1.0.2g ist das Problem weiterhin vorhanden.

Es ist auch unter CentOS 7 mit openssl-1.0.2k-16 vorhanden - und leider hilft die obige Problemumgehung dort nicht weiter, und gnutls-3.3.29-8 schlägt aufgrund unbekannter / unerwarteter TLS-Pakettypen fehl.