Openssl s_client neden uyumsuz bir CA dosyasına karşı bir sertifika doğrular?

openssl s_clientBöyle bir sertifika doğrulama hatası vermeye çalışıyorum :

$ 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

Web.de sunucusunun sertifikası TÜRKTRUST tarafından değil Deutsche Telekom CA tarafından onaylanmıştır, bu nedenle yukarıdaki komut başarısız olmalıdır, değil mi?

Ancak rapor ediyor:

    Verify return code: 0 (ok)

Neden?

Yani analog gnutls-cli komutu beklendiği gibi başarısız oluyor:

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

Bir çapraz kontrol yapmak, yani bunun yerine --x509cafile /etc/ssl/certs/ca-certificates.crtgnutls-cli kullanarak :

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

(bu da bekleniyor)

Ca-certificate.crt için openssl s_client baskılar.

    Verify return code: 0 (ok)

TÜRKTRUST ile aynı sonuç ...

Öncelikle -CApath(örn. / Etc / ssl / certs) - için varsayılan bir ayar kullanarak openssl şüphelendim - ama ben straceişlem sırasında sadece openargüman için sadece syscall bakın CAfile.

(tüm testler bir Ubuntu 10.04 sunucusunda yapılır)

Güncelleme: TÜRKTRUST sertifikasını bir Fedora 20 sistemine kopyaladım ve ilk openssl bildirimini yürüttüm - farklı bir sonuç elde ediyorum:

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

openssl s_clientUbuntu 10.04'te, -CApath ve -CAfile belirtilmiş olsa bile, sistem yüklü sertifikalar için hala varsayılan bir konum sorguladığı ortaya çıkıyor :

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

(strace çıktı)

Nerede:

$ 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

Dizin Ubuntu 10.04 üzerinde /usr/lib/ssl/certsbir sembolik bağlantı olduğundan, '/ etc / ssl' için selamlanırken strace günlüğündeki satır seçilmez .../etc/ssl/certsopen

Kaynak

Openssl-0.9.8k baktığımızda, içinde bulunduğu bu konunun kaynağı 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);

Nerede X509_get_default_cert_dirdöner /usr/lib/ssl/certsve X509_get_default_cert_dir_envdöner SSL_CERT_DIR.

Geçici çözüm

Böylece, beklenen davranışı elde etmek için aşağıdaki geçici çözüm Ubuntu 10.04 / openssl 0.9.8k altında kullanılabilir:

$ 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

Ve doğrulama başarısız olduğunda:

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

Mevcut durum

Bu bir Ubuntu sorunudur. Örneğin, Fedora 20'nin 1.0.1e openssl veya Fedora 29'un 1.1.1 openssl 1.1.1 ile bu sorun gerekli değildir, çünkü sorun yeniden üretilemez. Bu, -CAfileveya gibi bir seçenek belirtildiğinde -CApath, Fedora sistemlerindeki dizin arama listesine hiçbir varsayılan sertifika sistemi dizini eklenmediği anlamına gelir .

1.0.2g openssl ile Ubuntu 16'da sorun devam etmektedir.

Aynı zamanda CentOS 7'de openssl-1.0.2k-16 ile mevcut - ve ne yazık ki, yukarıdaki geçici çözüm orada yardımcı olmaz ve bilinmeyen / beklenmeyen TLS paket türleri nedeniyle gnutls-3.3.29-8 başarısız olur.