Openssl s_client çıktısını anlama


14

E-posta sağlayıcımız SSL sertifikasını değiştirdiğinden beri, mono tabanlı bir POP3 istemcisi, e-postaları indirmek için güvenli POP sunucularına bağlanmayı reddediyor. Diğer müşterilerin bir sorunu yoktur; Thunderbird ve Outlook; ne dışında tek bağlantı noktalarını kontrol edebilen en SSL denetleyicisi siteleri yapar bu bir . Sorunu saptamak için her iki sağlayıcıyla da çalışıyorum, ancak nihayet her ikisiyle de bir çıkma noktasına ulaştım, çünkü her iki sağlayıcıda da hatanın nerede olduğunu anlamak için her iki sağlayıcıya rehberlik edebilecek kadar bilgim yok.

Soruşturma sırasında dikkatim aşağıdaki iki komutun çıktısındaki farka çekildi (sertifikaları okunabilirlik için çıktıdan kaldırdım):

echo "" | openssl s_client -showcerts -connect pop.gmail.com:995

BAĞLANTILI (00000003)
derinlik = 2 / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
doğrulama hatası: num = 20: yerel yayıncı sertifikası alınamıyor
dönüşü doğrula: 0
---
Sertifika zinciri
 0 sn: / C = ABD / ST = Kaliforniya / L = Dağ Manzaralı / O = Google Inc / CN = pop.gmail.com
   i: / C = ABD / O = Google Inc / CN = Google İnternet Kurumu G2
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
 1 sn: / C = ABD / O = Google Inc / CN = Google İnternet Kurumu G2
   i: / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
 2 sn: / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Equifax Güvenli Sertifika Yetkilisi
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
---
Sunucu sertifikası
Subject = / C = ABD / ST = Kaliforniya / L = Dağ Manzaralı / O = Google Inc / CN = pop.gmail.com
yayıncı = / C = ABD / O = Google Inc / CN = Google İnternet Kurumu G2
---
İstemci sertifikası CA adı gönderilmedi
---
SSL anlaşması 3236 bayt okudu ve 435 bayt yazdı
---
Yeni, TLSv1 / SSLv3, Şifre RC4-SHA
Sunucu ortak anahtarı 2048 bit
Güvenli Yeniden Arama IS desteklenir
Sıkıştırma: NONE
Genişleme: HİÇBİRİ
SSL Oturum:
    Protokol: TLSv1
    Şifre: RC4-SHA
    Oturum Kimliği: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Oturum-ID CTX:
    Ana Anahtar: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Anahtar Arg: Yok
    Başlama Zamanı: 1397678434
    Zaman aşımı: 300 (sn.)
    Dönüş kodunu doğrulayın: 20 (yerel yayıncı sertifikası alınamıyor)
---
+ OK Gpop 69.3.61.10 c13mb42148040pdj'den gelen isteklere hazır
YAPILAN

echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995

BAĞLANTILI (00000003)
derinlik = 2 / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CAhatayı 
doğrula : num = 19: sertifika zincirinde kendinden imzalı sertifika
dönüşü doğrula: 0
---
Sertifika zinciri
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Bkz. Www.rapidssl.com/resources/cps (c) 14 / OU = Alan Adı Kontrolü Doğrulandı - RapidSSL (R) /CN=secure.emailsrvr.com
   i: / C = ABD / O = GeoTrust, Inc./CN=RapidSSL CA
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
 1 sn: / C = ABD / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
 2 sn: / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = ABD / O = GeoTrust Inc./CN=GeoTrust Global CA
----- SERTİFİKA BAŞLAYIN -----
----- SON SERTİFİKA -----
---
Sunucu sertifikası
Subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Bkz. www.rapidssl.com/resources/cps (c) 14 / OU = Alan Adı Kontrolü Doğrulandı - RapidSSL (R) /CN =secure.emailsrvr.com
yayıncı = / C = ABD / O = GeoTrust, Inc./CN=RapidSSL CA
---
İstemci sertifikası CA adı gönderilmedi
---
SSL anlaşması 3876 bayt okudu ve 319 bayt yazdı
---
Yeni, TLSv1 / SSLv3, Şifre DHE-RSA-AES256-SHA
Sunucu ortak anahtarı 2048 bit
Güvenli Yeniden Arama IS desteklenir
Sıkıştırma: NONE
Genişleme: HİÇBİRİ
SSL Oturum:
    Protokol: TLSv1
    Şifre: DHE-RSA-AES256-SHA
    Oturum Kimliği: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Oturum-ID CTX:
    Ana Anahtar: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Anahtar Arg: Yok
    Başlama Zamanı: 1397678467
    Zaman aşımı: 300 (sn.)
    Dönüş kodunu doğrulayın: 19 (sertifika zincirinde kendinden imzalı sertifika)
---
YAPILAN

Çünkü -CApathseçenek sağlandığında, komutlar herhangi bir hata üretmez , çünkü bu anlamlı olup olmadığını anlamaya çalışıyorum :

openssl s_client -CApath /etc/ssl/certs -showcerts -connect secure.emailsrvr.com:995

CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD, OU = 4159320284, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = secure.emailsrvr.com
verify return:1
...

openssl s_client -CApath /etc/ssl/certs -showcerts -connect pop.gmail.com:995

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
...

CAfile sertifikasını doğrudan GeoTrust'tan indirdikten-CAfile sonra seçeneği başarıyla kullanabilirim .

Yine de, Fog Creek bu sorunun sertifikada yattığını düşünüyor gibi görünüyor, çünkü sertifikayı mono'nun Trustmağazasına başarıyla eklemeyi denediler . Onlara katılmıyorum, ancak (yukarıda belirtildiği gibi) çoğu SSL denetleyicisi ya 995 numaralı bağlantı noktasını denetlemez ya da deneme sırasında başarılı olurken , SSL hatası 7 üreten bu sayfayı buldum .

Çıktıyı, sertifikada yanlış bir şey olmadığı anlamına gelecek şekilde doğru yorumlayabilir miyim?


2
"Sertifika zincirinde kendinden imzalı sertifika" hatası kırmızı bir ringa balığı olduğunu düşünüyorum. Kök CA her zaman kendinden imzalıdır, bu nedenle tam sertifika zincirini döndüren bir sunucu her zaman kendinden imzalı bir sertifika döndürür. Daha fazla bilgi burada .
bennettp123 17:14

2
Aslında, openssl s_clientvarsayılan olarak herhangi bir kök sertifika almıyor gibi görünüyor . Bunun yerine şunu deneyin: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsve muhtemelen kendinden imzalı hatanın kaybolduğunu göreceksiniz.
bennettp123 17:14

@ bennettp123 Sorunun sonuna doğru bu komutun çıktısını not ediyorum. Sertifikanın geçerli olduğu anlamına gelen komutun her iki sürümünün çıktısını anlamaya hakkım var mı?
jobu1324

evet, bu çıktıya göre, openssl sertifikanın geçerli olduğunu düşünüyor. Neden reddediliyor? Bilmiyorum. Organizasyon alanı ayarlanmamış olabilir, ancak bu sadece bir tahmindir.
bennettp123

Yanıtlar:


5

Yanıt (bu güvenlikte açıklandığı gibi ) SE zincirinde gördüğünüz iki GeoTrust Global CA sertifikasının aslında aynı sertifika olmadığı , biri diğerinden türetildiği yönündedir.

CA Çapraz imzalama nedeniyle!

GeoTrust Global CA sertifikası ilk oluşturulduğunda ve imzalandığında, hiçbir bilgisayar / tarayıcı / uygulama güven deposunda olmazdı.

GeoTrust kök CA sertifikasını (önceden var olan bir üne ve dağıtıma sahip) başka bir CA'ya sahip olarak , sonuçta elde edilen sertifika ("köprü" sertifikası olarak adlandırılır) artık GeoTrust kök CA sertifikası olmadan ikinci CA tarafından doğrulanabilir müşteri tarafından açıkça güvenilmesi gerekir.

Google, GeoTrust kök CA sertifikasının Çapraz İmzalı sürümünü sunduğunda, orijinaline güvenmeyen bir istemci, GeoTrust'u doğrulamak için sadece Equifax CA sertifikasını kullanabilir; böylece Equifax bir tür "eski" güven bağlantısı olarak işlev görür.


Bu nedenle iki sunucu zinciri farklıdır ve her ikisi de geçerlidir. Ama değil mutlaka tam olarak ve özellikle mono örneğinin truststore yüklü edilmeyen kökleri üzerinde net veriler olmadan, mono müşteri ile OP'ın sorun nedeni.
dave_thompson_085

0

SSL kontrolünü etkinleştirdiğinizde fetchmail ile benzer bir sorun vardı pop.gmail.com.

Equifax pem dosyasını indirdim ama olduğu gibi çalışmadı, c_rehash ssl/certshash değeri ile sembolik bir bağlantı oluşturan çalıştırmak zorunda kaldı , sonra sadece çalıştı.

Alternatif olarak, hash değeri koşarak da bilinir ...

openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed  -n /^[0-9]/p

https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.pem


Bağlantılı pem dosyasıyla ne yapacağınızı uzatabilir misiniz?
sebix

# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
chetangb

bazen okuduğum şey fetchmail openssl kütüphanelerini kullanıyor ve sadece cert productforums.google.com/forum/#!topic/gmail/tqjOmqxpMKY # ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10 yum libssl.so.10 'u sağlayan şey TLS uygulaması ile genel amaçlı bir şifreleme kütüphanesi Repo: base Matched from: Sağlar: libssl.so.10
chetangb

Lütfen cevabınızı uzatınız ve sorunun ne olabileceğini açıklayınız.
sebix

0

Sertifikalar oluştururken ve yapılandırırken, doğru yolu, sertifika adlarını vb. Belirtmek için openssl.cnfdosyayı da güncellemelisiniz (Debian - /etc/ssl/openssl.cnf), sonra komutu çalıştırabilir ve seçeneksiz olarak kontrol edebilirsiniz -CApath.

Buna göre uzak ana bilgisayarlar da bu durumda sertifikalarınızı düzgün bir şekilde kontrol edebilir.

İşte uygun openssl.cnfbölüm:

####################################################################
[ ca ]

default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = /etc/ssl  

1
Bu yanlış . default_ca(Herhangi bir) openssl yapılandırma dosyasında veri kullanılır sadece asla doğrulama için, 'ca' sorununa fayda ve isteğe bağlı Revoke certs için. Varsayılan doğrulama deposunu (yeniden derlemenin yanı sıra) değiştirmenin yolu ortam değişkenleri olan SSL_CERT_ {FILE, DIR}. Ancak (1) bir hata nedeniyle s_clientvarsayılanı (Nisan 2015 itibariyle planlanan düzeltme) kullanmaz (bu OP) yine de değiştirmek istemez.
dave_thompson_085
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.