Memahami output dari openssl s_client

14

Sejak penyedia email kami mengubah sertifikat SSL mereka, klien POP3 berdasarkan mono menolak untuk terhubung ke server POP aman mereka untuk mengunduh email. Klien lain tidak memiliki masalah; misalnya Thunderbird dan Outlook; tidak juga sebagian besar situs pemeriksa SSL yang mampu memeriksa port aneh kecuali yang ini . Saya telah bekerja dengan kedua penyedia dalam upaya untuk menunjukkan masalah, tetapi akhirnya menemui jalan buntu dengan keduanya, karena saya tidak cukup tahu tentang Sertifikat SSL untuk dapat membimbing penyedia mana pun untuk memahami di mana letak kesalahannya.

Selama penyelidikan, perhatian saya tertuju pada perbedaan dalam output dari dua perintah berikut (Saya telah menghapus sertifikat dari output untuk keterbacaan):

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

TERHUBUNG (00000003)
depth = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
verifikasi kesalahan: num = 20: tidak bisa mendapatkan sertifikat penerbit lokal
verifikasi pengembalian: 0
---
Rantai sertifikat
 0 s: / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
   i: / C = US / O = Google Inc / CN = Google Internet Authority G2
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
 1 s: / C = US / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Otoritas Sertifikat Aman Equifax
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
---
Sertifikat server
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
issuer = / C = US / O = Google Inc / CN = Google Internet Authority G2
---
Tidak ada nama klien sertifikat CA yang dikirim
---
Jabat tangan SSL telah membaca 3236 byte dan ditulis 435 byte
---
Baru, TLSv1 / SSLv3, Cipher adalah RC4-SHA
Kunci publik server adalah 2048 bit
Renegosiasi Aman Didukung
Kompresi: TIDAK ADA
Ekspansi: TIDAK ADA
SSL-Sesi:
    Protokol: TLSv1
    Cipher: RC4-SHA
    Sesi-ID: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Sesi-ID-ctx:
    Master-Key: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg: Tidak Ada
    Waktu Mulai: 1397678434
    Batas waktu: 300 (detik)
    Verifikasi kode pengembalian: 20 (tidak dapat memperoleh sertifikat penerbit lokal)
---
+ OK Gpop siap untuk permintaan dari 69.3.61.10 c13mb42148040pdj
DIBUAT

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

TERHUBUNG (00000003)
depth = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
verifikasi kesalahan: num = 19: sertifikat yang ditandatangani sendiri dalam rantai sertifikat
verifikasi pengembalian: 0
---
Rantai sertifikat
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Lihat www.rapidssl.com/resources/cps (c) 14 / OU = Kontrol Domain Divalidasi - RapidSSL (R) /CN=secrvrrrrr.com
   i: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
 1 s: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- MEMULAI SERTIFIKAT -----
----- AKHIR SERTIFIKAT -----
---
Sertifikat server
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Lihat www.rapidssl.com/resources/cps (c) 14 / OU = Kontrol Domain Divalidasi - RapidSSL (R) /CN=secrrrrrrr.com
issuer = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Tidak ada nama klien sertifikat CA yang dikirim
---
Jabat tangan SSL telah membaca 3876 byte dan menulis 319 byte
---
Baru, TLSv1 / SSLv3, Cipher adalah DHE-RSA-AES256-SHA
Kunci publik server adalah 2048 bit
Renegosiasi Aman Didukung
Kompresi: TIDAK ADA
Ekspansi: TIDAK ADA
SSL-Sesi:
    Protokol: TLSv1
    Sandi: DHE-RSA-AES256-SHA
    Sesi-ID: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Sesi-ID-ctx:
    Master-Key: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg: Tidak Ada
    Waktu Mulai: 1397678467
    Batas waktu: 300 (detik)
    Verifikasi kode kembali: 19 (sertifikat yang ditandatangani sendiri dalam rantai sertifikat)
---
DIBUAT

Saya telah mencoba untuk memahami apakah ini bermakna, karena ketika -CApathopsi disediakan, perintah tidak menghasilkan kesalahan:

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

Saya juga dapat menggunakan -CAfileopsi ini dengan sukses setelah mengunduh sertifikat CAfile langsung dari GeoTrust.

Namun demikian, Fog Creek tampaknya berpikir bahwa masalahnya ada pada sertifikat, karena mereka telah mencoba menambahkan sertifikat ke Trusttoko mono tanpa hasil. Saya tidak setuju dengan mereka, tetapi (seperti yang disebutkan di atas) sementara sebagian besar pemeriksa SSL tidak memeriksa port 995 atau berhasil selama upaya, saya menemukan halaman ini yang menghasilkan kesalahan SSL 7.

Apakah saya mengartikan output dengan benar berarti tidak ada yang salah dengan sertifikat?

ssl-certificate openssl jobu1324
sumber
2
Saya pikir kesalahan "sertifikat yang ditandatangani sendiri dalam rantai sertifikat" adalah herring merah. Root CA selalu ditandatangani sendiri, sehingga server yang mengembalikan rantai sertifikat lengkapnya akan selalu mengembalikan sertifikat yang ditandatangani sendiri. Info lebih lanjut di sini .
bennettp123
2
Sebenarnya, tampaknya openssl s_clienttidak mengimpor sertifikat root apa pun secara default. Coba ini sebagai gantinya:, openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsdan Anda mungkin akan menemukan bahwa kesalahan yang ditandatangani sendiri hilang.
bennettp123
@ bennettp123 Saya perhatikan output dari perintah itu di bagian bawah pertanyaan. Apakah saya benar untuk memahami output dari kedua versi perintah yang berarti bahwa sertifikat itu valid?
jobu1324
ya, menurut keluaran itu, openssl menganggap sertifikat itu valid. Kenapa ditolak? Saya tidak tahu Mungkin karena bidang Organisasi tidak disetel, tapi itu hanya tebakan.
bennettp123

Jawaban:

5

Jawabannya (seperti yang dijelaskan dalam posting security.SE ini ) adalah bahwa dua sertifikat GeoTrust Global CA yang Anda lihat dalam rantai sebenarnya bukan sertifikat yang sama , satu berasal dari yang lain.

Karena penandatanganan silang CA!

Ketika sertifikat GeoTrust Global CA pertama kali dibuat dan ditandatangani, tidak ada komputer / browser / aplikasi akan memilikinya di toko kepercayaan mereka.

Dengan memiliki CA lain (dengan reputasi dan distribusi yang sudah ada sebelumnya) menandatangani CA root GeoTrust, sertifikat yang dihasilkan (disebut sebagai "jembatan" sertifikat) sekarang dapat diverifikasi oleh CA kedua, tanpa sertifikat CA akar GeoTrust memiliki untuk dipercaya oleh klien secara eksplisit.

Saat Google menyajikan versi cross-ditandatangani dari CA CA GeoTrust root, klien yang tidak mempercayai yang asli hanya dapat menggunakan CA CA Equifax untuk memverifikasi GeoTrust - jadi Equifax bertindak sebagai semacam "anchor trust trust".

Mathias R. Jessen
sumber
Itu sebabnya dua rantai server berbeda namun keduanya valid. Tetapi itu tidak selalu menjadi alasan masalah OP dengan klien mono, tanpa data yang jelas tentang akar mana yang dan tidak diinstal di truststore mono instance tertentu.
dave_thompson_085
0

Punya masalah serupa dengan fetchmail ketika saya mengaktifkan ssl check for pop.gmail.com.

Saya mengunduh berkas Equifax tetapi tidak berfungsi sebagaimana mestinya, harus dijalankan c_rehash ssl/certsyang membuat tautan simbolik dengan nilai hash, kemudian hanya berfungsi.

Atau, nilai hash juga bisa dikenal dengan menjalankan ... 

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

chetangb
sumber
Bisakah Anda memperluas apa yang harus dilakukan dengan file-file yang ditautkan?
sebix
# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
chetangb
apa yang saya baca beberapa waktu lalu adalah fetchmail menggunakan openssl libs dan hanya terlihat oleh nilai hash dari productforums.google.com/forum/#!topic/gmail/tqjOmqxpMKY # ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10 yum whatprovides libssl.so.10 openssl-libs-1.0.1e-42.el7.i686: Perpustakaan kriptografi tujuan umum dengan implementasi TLS Repo: base Matched dari: Menyediakan: libssl.so.10
chetangb
Harap sampaikan jawaban Anda dan jelaskan apa masalahnya, yang ingin Anda capai.
sebix
0

Saat membuat dan mengkonfigurasi sertifikat, seseorang harus memperbarui openssl.cnffile juga (Debian - /etc/ssl/openssl.cnf), untuk menunjukkan jalur yang tepat, nama sertifikat, dll., Maka Anda dapat menjalankan perintah dan memeriksa mereka tanpa -CApathopsi.

Dan host jarak jauh juga dapat memeriksa sertifikat Anda dengan benar dalam kasus ini.

Inilah bagian yang sesuai openssl.cnf:

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl
pengguna155270
sumber
1
Ini salah . The default_cadata dalam (ada) openssl file konfigurasi digunakan hanya untuk 'ca' utilitas untuk masalah dan sertifikat opsional mencabut, tidak pernah untuk verifikasi. Cara untuk mengubah penyimpanan verifikasi default (selain mengkompilasi ulang) adalah dengan variabel lingkungan SSL_CERT_ {FILE, DIR}. Namun (1) karena bug s_clienttidak menggunakan default (perbaikan direncanakan pada April 2015) yang (2) OP ini tidak mau berubah.
dave_thompson_085