OpenSSL nie odbiera urzędów certyfikacji w folderze certyfikatów

Mamy problem z brakiem curlpołączenia z serwerem HTTPS:

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112 jest SSL_R_TLSV1_UNRECOGNIZED_NAMEw środku ssl.h.

Jeśli spróbuję openssl s_client -connect the-problem-site.com:443zamiast tego, zobaczę

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

tzn. wygląda na to, że problem polega na tym, że nie ufa /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Jednak ten certyfikat jest zainstalowany: jest /etc/ssl/certs/GeoTrust_Global_CA.pem, a jeśli zamiast tego uruchamiam

openssl s_client -connect the-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

wtedy wszystko działa. Cert jest również obecny jako plik o nazwie skrótu b0f3e76e.0i znajduje się w ca-certificates.crt. Jednak, o ile widzę, ani curl, ani openssl nie próbują czytać żadnych certyfikatów; jeśli to ja strace, to nie ma próby czytania /usr/lib/ssl/certsani /etc/ssl/certswcale, nawet z błędami. Czyta jednak openssl.cnf. Uciekliśmy update-ca-certificates.

To jest Ubuntu 10.04 z openssl 0.9.8k. Możemy odtworzyć problem na dwóch osobnych instalacjach (choć możliwe, że jeden jest klonem drugiego od dawna). Jeśli wypróbuję ten sam test na maszynie Wirtualnej CentOS z openssl 0.9.8e, to działa dobrze i widzę, że czyta plik certyfikatu strace. Nie ma równoważnego dostępu do plików w tym samym punkcie w ciągach Ubuntu. Jeśli skopiuję openssl.cnfplik z maszyny Wirtualnej CentOS na maszyny Ubuntu, nie ma to znaczenia. Nie ma nic oczywistego w środowisku lub pliku .rc, który mógłby to powodować.

Jakieś pomysły, co robię źle? Czy powinno to działać, tj. Czy openssl i curl powinny automatycznie pobierać zainstalowane CA z wiersza poleceń? Jak to jest skonfigurowane? Dzięki!

Kolejny punkt danych: przy czystej instalacji 13 serwerów curlpobiera plik certyfikatów i działa dobrze. openssl s_clientjednak nadal nie. Dlaczego miałoby to być?

W twoim systemie jest kilka bibliotek kryptograficznych:

• OpenSSL (złoty standard z licencją typu BSD (bardzo bezpłatną), która zawiera nieco problematyczną klauzulę (zapobiegającą kompatybilności z GPL, ale nic „złego”) ograniczającą jej przyjęcie w świecie GNU)
• GnuTLS (zamiennik z FSF; występuje w dwóch wersjach: na licencji LGPLv2 (ale nieobsługiwany) i na licencji LGPLv3 (a zatem niekompatybilny z programami opartymi tylko na GPLv2); historycznie nie tak funkcjonalny jak OpenSSL, nieco bardziej wadliwy, ale bardziej rygorystyczny co również zwiększa bezpieczeństwo)
• NSS (biblioteka Netscape / Mozilla, rzadko używana na zewnątrz; powolne przyjmowanie nowych standardów)
• drobne, takie jak PolarSSL, MatrixSSL, NaCl / Salt

Wszystkie mają oczywiście podobieństwa i różnice. Oprogramowanie, które ich używa (do celów kryptograficznych lub do korzystania z SSL / TLS) czasami obsługuje używanie więcej niż jednej z tych bibliotek (na przykład Lynx, przeglądarka internetowa, jest zwykle połączona z OpenSSL, ale obsługuje również GnuTLS (tylko nie tak dobrze) w aby uspokoić lud GNU).

cURL jest także jednym z projektów wspierających korzystanie z jednej z trzech głównych bibliotek kryptograficznych. Wynika to głównie z tego, że cURL jest, przede wszystkim, biblioteką przeznaczoną do użycia przez inne programy, gdy chcą pobierać (a nawet przesyłać) rzeczy za pomocą połączeń http, ftp itp. Narzędzie curlwiersza polecenia może pochodzić z jednego z tych wariantów.

Teraz jestem całkiem pewien, że problem, który pojawia się w przypadku świeżo zainstalowanego systemu, jest następujący:

Zarówno OpenSSL, jak i GnuTLS obsługują /etc/ssl/certs/<hash>.<number>katalogi CA w stylu. Jednak OpenSSL w wersji 0.x i GnuTLS używają innego algorytmu do obliczenia wspomnianego skrótu niż w OpenSSL w wersji 1.x. (Oba mogą istnieć w systemie; jeśli różne certyfikaty mają ten sam skrót , po prostu używasz dla nich różnej liczby . Ale z jakiegoś powodu ca-certificatespakiet Debian / Ubuntu nie robi tego.) Ponadto niektóre wersje GnuTLS nie obsługa za pomocą katalogu, ale tylko za pomocą pliku /etc/ssl/certs/ca-certificates.crt(który jest zwykle zarządzany przez ca-certificatesskrypty opiekuna pakietu, ale może się różnić); Wygląda na to, że korzystasz ze starszej wersji, więc może to ci się podobać.

openssl s_clientdomyślnie (czyli bez -CApathlub -CAfileopcji) nie wygląda wszędzie na certyfikatach.

Twoja curlz uaktualnionej instalacji najprawdopodobniej używa innej biblioteki kryptograficznej niż curlz nowej instalacji.

Spróbuj openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443oprócz openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443naśladować zachowanie starszych wersjach gnutls.

Dokładnie sprawdź, czy gdzieś w twoim systemie jest OpenSSL 1.x (Ubuntu znany jest z wprowadzania ważnych aktualizacji nawet do wersji LTS), a jeśli tak, sprawdź skrót pliku:

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

Zwykle albo drugie i trzecie polecenie powinno zakończyć się niepowodzeniem (OpenSSL 0.x), albo pierwsze i trzecie polecenie powinno wyświetlać ten sam skrót, ale drugie powinno wyświetlać inny skrót (OpenSSL 1.x). GnuTLS użyłby danych wyjściowych z drugiego polecenia (jeśli zainstalowany jest OpenSSL 1.x); jeśli zainstalowany jest OpenSSL 0.x, to ten sam skrót. Możesz tworzyć takie dowiązania symboliczne ręcznie.

Mogę zaktualizować ten wpis po przesłaniu opinii na temat debugowania.