web-dev-qa-db-fra.com

Pourquoi OpenSSL S_CLIENT vérifie-t-il un cert contre un caafile incompatible?

J'essaie de donner une erreur de vérification de certificat avec openssl s_client comme ça:

$ 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

Le certificat du serveur Web.de est certifié par la Deutsche Telekom CA, pas Turktrust, la commande ci-dessus devrait donc échouer, non?

Mais il rapporte:

    Verify return code: 0 (ok)

Pourquoi?

Je veux dire qu'une commande analogique gnutls-cli échoue comme prévu:

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

Faire un crosscheck, c'est-à-dire en utilisant à la place --x509cafile /etc/ssl/certs/ca-certificates.crt avec gnoutls-cli je reçois:

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

(qui est également prévu)

Impressions openssl S_Client pour CA-Certificats.Crt:

    Verify return code: 0 (ok)

Le même résultat que pour Turktrust ...

D'abord, j'ai suspecté openssl à l'aide d'un paramètre par défaut pour -CApath (c'est-à-dire/etc/ssl/certs) - mais quand je strace le processus Je viens voir juste le open syscall pour l'argument de CAfile.

(Tous les tests effectués sur un serveur Ubuntu 10.04)

Mise à jour : J'ai copié le certificat Turktrust vers un système Fedora 20 et exécuté la première instruction OpenSSL - y a obtenu un résultat différent:

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

Il s'avère que le openssl s_client Sur Ubuntu 10.04 interroge toujours un emplacement par défaut pour les certificats installés du système, même si -CApath -et-CAfile Sont spécifiés:

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

(sortie de la strace)

Où:

$ 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

Le répertoire /usr/lib/ssl/certs Est un lien symbolique à /etc/ssl/certs Sur Ubuntu 10.04, donc la ligne open _ ligne du journal de la strace n'est pas sélectionnée lors de la greping pour '/ etc/ssl' ...

La source

En regardant l'openssl-0.9.8k, la source de ce numéro est située dans 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);

Où X509_get_default_cert_dir Retourne /usr/lib/ssl/certs Et X509_get_default_cert_dir_env Retourne SSL_CERT_DIR.

Workaround

Ainsi, on peut utiliser la solution suivante sous Ubuntu 10.04/OpenSSL 0.9.8k pour obtenir le comportement attendu:

$ 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

Et avec la vérification échoue:

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

Situation actuelle

Ceci est une question Ubuntu. Par exemple, avec OpenSSL 1.0.1e de Fedora 20 ou Fedora 29, OpenSSL 1.1.1, cette solution de contournement n'est pas nécessaire, car la question ne peut être reproduite. Cela signifie que lorsque vous spécifiez une option comme -CAfile Ou -CApath, Aucun répertoire système de certificat par défaut est ajouté à la liste de recherche d'annuaire sur les systèmes Fedora.

Sur Ubuntu 16 avec OpenSSL 1.0.2G, le problème est toujours présent.

Il est également présent sur Centos 7 avec OpenSSL-1.0.2K-16 - et malheureusement, la solution de contournement ci-dessus ne l'aide pas et les gnoutls-3.3.29-8 échouent en raison de types de paquets TLS inconnus/inattendus.

10
maxschlepzig