Perché openssl s_client verifica un certificato contro un file CA non corrispondente?

Sto cercando di generare un errore di verifica del certificato in openssl s_clientquesto modo:

$ 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

Il certificato del server web.de è certificato dalla Deutsche Telekom CA, non da TURKTRUST, quindi il comando sopra dovrebbe fallire, giusto?

Ma riporta:

    Verify return code: 0 (ok)

Perché?

Voglio dire che un comando analogico gnutls-cli fallisce come previsto:

$ { 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...

Facendo un controllo incrociato, cioè usando invece --x509cafile /etc/ssl/certs/ca-certificates.crtcon gnutls-cli ottengo:

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

(che è anche previsto)

Openssl s_client stampe per ca-certificati.crt:

    Verify return code: 0 (ok)

Lo stesso risultato di TURKTRUST ...

Per prima cosa sospettavo che openssl usasse un'impostazione predefinita per -CApath(es. / Etc / ssl / certs) - ma quando ho straceil processo vedo solo la opensyscall per l'argomento di CAfile.

(tutti i test eseguiti su un server Ubuntu 10.04)

Aggiornamento: ho copiato il certificato TURKTRUST su un sistema Fedora 20 ed eseguito la prima istruzione openssl - lì ottengo un risultato diverso:

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

Si scopre che openssl s_clientsu Ubuntu 10.04 richiede ancora una posizione predefinita per i certificati installati dal sistema, anche se -CApath e -CAfile sono specificati:

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

(uscita strace)

Dove:

$ 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

La directory /usr/lib/ssl/certsè un link simbolico a /etc/ssl/certsUbuntu 10.04, quindi la openlinea dal registro strace non è selezionata quando si esegue il grepping per '/ etc / ssl' ...

fonte

Guardando l'openssl-0.9.8k, la fonte di questo problema si trova a 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);

Dove X509_get_default_cert_dirritorna /usr/lib/ssl/certse X509_get_default_cert_dir_envritorna SSL_CERT_DIR.

Soluzione

Pertanto, è possibile utilizzare la seguente soluzione alternativa in Ubuntu 10.04 / openssl 0.9.8k per ottenere il comportamento previsto:

$ 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

E con la verifica fallisce:

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

Situazione attuale

Questo è un problema di Ubuntu. Ad esempio, con Fedora 20's openssl 1.0.1e o Fedora 29's openssl 1.1.1, questa soluzione alternativa non è necessaria, poiché il problema non può essere riprodotto. Ciò significa che quando si specifica un'opzione come -CAfileo -CApath, nessuna directory di sistema di certificato predefinita viene aggiunta all'elenco di ricerca delle directory sui sistemi Fedora.

Su Ubuntu 16 con openssl 1.0.2g il problema è ancora presente.

È presente anche su CentOS 7 con openssl-1.0.2k-16 - e sfortunatamente, la soluzione sopra descritta non aiuta in questo caso e gnutls-3.3.29-8 fallisce a causa di tipi di pacchetti TLS sconosciuti / imprevisti.