Вопросы Теги

Соединение с использованием URL клиентские работы OpenSSL, но вихревые сбои

У меня есть сервер CentOS 5.9, с которого я должен установить связи SSL с другим сервером. Удаленному серверу подписал сертификат в конечном счете GeoTrust, Глобальный Приблизительно. Во время записи этот сертификат является вторым, перечисленным на странице загрузки GeoTrust. Я получаю непоследовательные результаты, в зависимости от того, использую ли я OpenSSL или завихрение для устанавливания связи:

openssl s_client -connect <server>:443 -CAfile /path/to/GeoTrustCA.pem

хорошо работает, но

curl --cacert /path/to/GeoTrustCA.pem https://<server>/

сбои со стандартом "не могли проверить сертификат" ошибка.

Вот детали инструментов, которые я использую:

$ curl --version 
curl 7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 Protocols: tftp ftp telnet dict
ldap http file https ftps  Features: GSS-Negotiate IDN IPv6 Largefile
NTLM SSL libz

и

$ openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

Я озадачен. Сервер, с которым я соединяюсь, работал без очевидных проблем в течение многих лет: я никогда не слышал ни о ком или любой системной неспособности соединиться с ним как это.

3
задан 13 November 2014 в 02:28
1 ответ

Мне было любопытно, так что я провел кое-какое тестирование. Из того, что я могу сказать, есть принципиальная разница в том, что openssl и curl принимают во внимание при использовании своих корневых CA-переключателей (-CAfile и --cacert соответственно).

При использовании переключателя --cacert в скрутке -Cacert, кажется, что во время проверки ТОЛЬКО используется корень, указанный администратором. Например, я скачал файл GeoTrust PEM, о котором Вы упоминали ранее, и попробовал использовать его для получения страницы от yahoo: 

[foo@foobox tmp]# curl --cacert /tmp/geotest.pem https://info.yahoo.com/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Теперь я попробовал тот же тест с openssl :

[foo@foobox tmp]# openssl s_client -connect info.yahoo.com:443 -CAfile /tmp/geotest.pem
CONNECTED(00000003)
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify return:1
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 /C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
...
...
...
...
...
...
SSL handshake has read 5342 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: 6CAE87314ED66784B25C0FB36197D822CC73032FBFF30AD9E37CFF3D1678EBCC
    Session-ID-ctx:
    Master-Key: 6B9135F16512A251AB6DBEF62C6B261EC31DB90A0076C33DD67B27EAAB83A0333D50B1B7F10727DE47AB051A9C3A0499
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1415842989
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Обратите внимание, что в первоначальном описании цепочки нет ошибок и что в нем указан Verify code (Проверить код возврата): 0 (ok) внизу.

Таким образом, хотя GeoTrust вообще не упоминается в цепочке сертификатов, OpenSSL каким-то образом способен проверить/проверить корень.

Хммм...

Это заставило меня задуматься о том, где находится стандартный траст-магазин для openssl... по каким-то причинам мне было трудно найти информацию о нем в интернете (я уверен, что он хорошо документирован, и я просто слепой). Просматривая свою систему, я наткнулся на /etc/pki/tls/certs/ca-bundle.crt

Я искал в ca-bundle.crt и удалил корень, который yahoo использует (/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority) и снова выполнил ту же самую exact команду: 

[foo@foobox tmp]# openssl s_client -connect info.yahoo.com:443 -CAfile /tmp/geotest.pem
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./CN=www.yahoo.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
...
...
...
...
...
...
...
...
---
SSL handshake has read 5342 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: 09D998B153574D5C785BFF191B99CAB8BFCEF4DAC482F75A601886E668BF9CE6
    Session-ID-ctx:
    Master-Key: 1F98289FEB5926B8814D5E3B163FB40CC03BBC5C2D8A0045C0DFF0532458F18F722D5FD53155327B0A78627E3FE909E5
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1415843859
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

На этот раз мы получили ошибки проверки.

Soooooo, с учетом всего вышесказанного, я склонен заподозрить следующее:

  • Корневой сертификат, который вы используете, может на самом деле не совпадать с корнем, который вы должны использовать.
  • curl ТОЛЬКО использует корень, который вы говорите ему использовать.
  • openssl использует корень, который вы указываете ему ANNNND, независимо от того, какой корень находится в его трастовом хранилище по умолчанию.

Что касается того, почему openssl делает это? Понятия не имею. В документации для этого переключателя не упоминается этот рабочий процесс/поведение:

-файлCAfile file

Файл, содержащий доверенные сертификаты для использования во время аутентификации сервера и при попытке построения цепочки клиентских сертификатов.

Возможно, кто-нибудь другой может изучить код для openssl и проработать его подробнее.

2
ответ дан 3 December 2019 в 07:01

Теги

Похожие вопросы