С тех пор, как наш провайдер электронной почты изменил свой сертификат SSL, клиент POP3 на основе mono отказывается подключаться к своему защищенному серверу POP для загрузки писем. У других клиентов нет проблем; например Thunderbird и Outlook; и большинство сайтов проверки SSL, способных проверять нечетные порты, кроме вот этот. Я работал с обоими поставщиками, пытаясь определить проблему, но, наконец, зашел в тупик с обоими, поскольку я недостаточно знаю о сертификатах SSL, чтобы иметь возможность направить любого поставщика, чтобы понять, в чем заключается ошибка.
В ходе расследования мое внимание привлекла разница в выводе следующих двух команд (я удалил сертификаты из вывода для удобства чтения):
echo "" | openssl s_client -showcerts -connect pop.gmail.com:995
CONNECTED(00000003) depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify ошибка: число = 20: невозможно получить сертификат местного эмитента verify return:0 --- Certificate chain 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 -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 2 с: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA i: / C = US / O = Equifax / OU = Центр сертификации Equifax Secure -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- --- Server certificate 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 --- No client certificate CA names sent --- SSL handshake has read 3236 bytes and written 435 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06 Session-ID-ctx: Master-Key: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2 Key-Arg : None Start Time: 1397678434 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- +OK Gpop ready for requests from 69.3.61.10 c13mb42148040pdj DONE
echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995
CONNECTED(00000003) depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify ошибка: число = 19: самоподписанный сертификат в цепочке сертификатов verify return:0 --- Certificate chain 0 s:/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- 2 с: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- --- Server certificate subject=/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA --- No client certificate CA names sent --- SSL handshake has read 3876 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161 Session-ID-ctx: Master-Key: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F Key-Arg : None Start Time: 1397678467 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- DONE
Я пытался понять, имеет ли это смысл, потому что когда -CApath
предусмотрена опция, команды не вызывают ошибок:
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
вариант успешно после загрузки Сертификат CAfile прямо из GeoTrust.
Тем не менее, Fog Creek, похоже, думает, что проблема связана с сертификатом, потому что они пытались добавить сертификат в моно. Trust
магазин без успеха. Я бы не согласился с ними, но (как упоминалось выше), хотя большинство средств проверки SSL либо не проверяют порт 995, либо преуспевают во время попытки, я обнаружил эта страница что вызывает ошибку SSL 7.
Правильно ли я интерпретирую вывод как означающий, что с сертификатом все в порядке?
Ответ (как объясняется в этом security.SE сообщение) состоит в том, что два GeoTrust Global CA сертификат, который вы видите в цепочке, на самом деле не тот же сертификат, одно происходит от другого.
Когда сертификат GeoTrust Global CA был впервые создан и подписан, ни один компьютер / браузеры / приложения не имели его в своем хранилище доверенных сертификатов.
Имея другой ЦС (с уже существующей репутацией и распространением) подписывает сертификат корневого ЦС GeoTrust, полученный сертификат (именуемый «мостовой» сертификат) теперь может быть проверен вторым ЦС без необходимости доверять сертификату корневого ЦС GeoTrust. клиентом явно.
Когда Google представляет версию сертификата корневого CA GeoTrust с перекрестной подписью, клиент, не доверяющий оригиналу, может просто использовать сертификат CA Equifax для проверки GeoTrust, поэтому Equifax действует как своего рода "устаревший" якорь доверия.
Была аналогичная проблема с fetchmail, когда я включил проверку ssl для pop.gmail.com
.
Я загрузил PEM-файл Equifax, но он не работал как есть, пришлось запустить c_rehash ssl/certs
который создал символическую ссылку с хеш-значением, затем он просто работал.
Кроме того, значение хеш-функции можно узнать, запустив ...
openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed -n /^[0-9]/p
При создании и настройке сертификатов следует обновить openssl.cnf
файл (Debian - /etc/ssl/openssl.cnf
), чтобы указать правильный путь, имена сертификатов и т. д., затем вы можете запустить команду и проверить их без -CApath
вариант.
И, соответственно, удаленные хосты также могут правильно проверить ваши сертификаты в этом случае.
Вот соответствующий openssl.cnf
раздел:
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /etc/ssl