OpenSSL certs klasöründeki CA'ları almıyor

curlBir HTTPS sunucusuna bağlanmayla ilgili sorun yaşıyoruz :

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

1112 SSL_R_TLSV1_UNRECOGNIZED_NAMEçıktı ssl.h.

Ben çalışırsanız openssl s_client -connect the-problem-site.com:443o zaman bunun yerine bakın

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   

yani sorun, güvenmemesidir /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Ancak bu sertifika yüklenir: bu /etc/ssl/certs/GeoTrust_Global_CA.pemve eğer çalıştırırsam

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

o zaman her şey işe yarar. Sertifika ayrıca karma adlı bir dosya olarak bulunur b0f3e76e.0ve dosyada bulunur ca-certificates.crt. Ancak, görebildiğim kadarıyla, ne curl ne de openssl herhangi bir sertifikayı okumaya çalışıyor; eğer ben straceonlardan biriyse, hatalarla bile olsa, hiç okuma /usr/lib/ssl/certsya da /etc/ssl/certshiç okuma denemesi olmaz. Yine de openssl.cnf okur. Biz kaçtık update-ca-certificates.

Bu Ubuntu 10.04 ve 0.9.8k açıldı. Sorunu iki ayrı kurulumda yeniden üretebiliriz (ancak birinin diğerinin klonu geri dönüşü olabilir). Aynı testi openssl 0.9.8e ile bir CentOS VM üzerinde denerseniz, o zaman iyi çalışıyor ve sertifika dosyasını okuduğunu görebiliyorum strace. Ubuntu şeritlerinde aynı noktada eşdeğer bir dosya erişimi yoktur. openssl.cnfDosyayı CentOS VM'den Ubuntu makinelerine kopyalarsam fark etmez. Ortamda veya buna neden olabilecek bir .rc dosyasında belirgin bir şey yok.

Yanlış yaptığım hakkında bir fikrin var mı? Bu çalışır mı, yani openssl ve curl kurulu CA'ları komut satırından otomatik olarak almalı mı? Bu nasıl yapılandırılır? Teşekkürler!

Başka bir veri noktası: 13 sunucunun temiz bir kurulumunda curl, sertifika dosyasını alır ve iyi çalışır. openssl s_clientyine de değil. Neden olsun ki?

Sisteminizde birkaç şifreleme kütüphanesi var:

• OpenSSL (GNU dünyasında benimsenmesini sınırlayan, biraz sorunlu bir madde içeren (GPL uyumluluğunu önleyen, ancak “kötü” bir şey olmayan) BSD tarzı (çok ücretsiz) lisanslı altın standart)
• GnuTLS (FSF'den değiştirme; LGPLv2 lisanslı (ancak bakımsız) ve LGPLv3 lisanslı (ve böylece yalnızca GPLv2 programlarıyla uyumlu değildir); Tarihsel olarak OpenSSL kadar özellikli değil, biraz daha buggy, ancak daha katı bu da güvenliği artırır)
• NSS (Netscape / Mozilla'nın kütüphanesi, nadiren dışarıda kullanılır; yeni standartları benimsemek yavaş)
• PolarSSL, MatrixSSL, NaCl / Tuz gibi küçük olanlar

Hepsinin elbette benzerlikleri ve farklılıkları var. Bunları kullanan (şifreleme amacıyla veya SSL / TLS kullanmak için) yazılım bazen bu kitaplıklardan birden fazlasını (örneğin web tarayıcısı Lynx,) normalde OpenSSL'ye bağlıdır, ancak GnuTLS'yi de destekler (o kadar iyi değil) GNU halkını yatıştırmak için).

cURL ayrıca üç büyük kripto kütüphanesinden birinin kullanılmasını destekleyen projelerden biridir. Bunun nedeni, cURL'nin birincil olarak, http, ftp vb. Bağlantıları kullanarak bir şeyleri indirmek (hatta yüklemek) istedikleri zaman diğer programlar tarafından kullanılması amaçlanan bir kitaplık olmasıdır. curlKomut satırı aracı, bu varyantlar birinden gelebilir.

Şimdi, yeni kurulmamış sistemde gördüğünüz sorunun şu olduğundan eminim:

OpenSSL ve GnuTLS'nin her ikisi de /etc/ssl/certs/<hash>.<number>-style CA dizinlerini kullanmayı destekler . Ancak OpenSSL sürüm 0.x ve GnuTLS, yukarıda belirtilen karmayı hesaplamak için OpenSSL sürüm 1.x'in kullandığından farklı bir algoritma kullanır. (Her ikisi de bir sistem üzerinde birlikte çalışabilir; farklı sertifikalar aynı karma değere sahipse, onlar için farklı bir sayı kullanırsınız . Ancak bazı nedenlerden dolayı Debian / Ubuntu'nun ca-certificatespaketi bunu yapmıyor gibi görünüyor.) Ayrıca, GnuTLS'nin bazı sürümleri dizini kullanarak destek, ancak yalnızca bir dosya kullanarak /etc/ssl/certs/ca-certificates.crt(genellikle ca-certificatespaketin bakım komut dosyaları tarafından yönetilir , ancak sapabilir); eski bir sürüm kullanıyor gibi görünüyorsunuz, bu yüzden vurduğunuz şey bu olabilir.

openssl s_clientvarsayılan olarak (yani -CApathveya -CAfileseçeneği olmadan ) hiçbir yerde sertifika aramaz .

Sizin curlyükseltilmiş yüklemesinden büyük olasılıkla farklı bir kripto kütüphanesini kullanan curltaze yüklemesinden.

Daha eski GnuTLS sürümlerinin davranışını taklit openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443etmeye openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443de çalışın .

Sisteminizde herhangi bir yerde bir OpenSSL 1.x olup olmadığını iki kez kontrol edin (Ubuntu, LTS sürümlerinde bile büyük güncellemeleri gizlemekle bilinir) ve evetse, dosyanın karmasını kontrol edin:

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

Normalde, ya ikinci ve üçüncü komut başarısız olmalıdır (OpenSSL 0.x) ya da birinci ve üçüncü komut aynı karmayı göstermelidir, ancak ikinci komut farklı bir karmayı görüntülemelidir (OpenSSL 1.x). GnuTLS, ikinci komuttaki çıktıyı kullanır (OpenSSL 1.x yüklüyse); OpenSSL 0.x yüklüyse aynı karma değerdedir. Bu tür simgeleri manuel olarak oluşturabilirsiniz.

Hata ayıklama geri bildirimi sağladıktan sonra bu yayını güncelleyebilirim.