OpenSSL no recoge CAs en la carpeta certs

Tenemos problemas para curlno conectarnos a un servidor HTTPS:

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

1112 está SSL_R_TLSV1_UNRECOGNIZED_NAMEadentro ssl.h.

Si lo intento, openssl s_client -connect the-problem-site.com:443entonces veo

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   

es decir, parece que el problema es que no confía /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Sin embargo, ese certificado está instalado: es /etc/ssl/certs/GeoTrust_Global_CA.pem, y si en cambio ejecuto

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

entonces todo funciona. El certificado también está presente como un archivo con nombre hash b0f3e76e.0y está en ca-certificates.crt. Sin embargo, hasta donde puedo ver, ni curl ni openssl intentan leer ningún certificado; si straceellos entonces no hay intento de leer /usr/lib/ssl/certso /etc/ssl/certsen absoluto, ni siquiera con errores. Sin embargo, sí lee openssl.cnf. Hemos corrido update-ca-certificates.

Esto es Ubuntu 10.04 con openssl 0.9.8k. Podemos reproducir el problema en dos instalaciones separadas (aunque es posible que uno sea un clon del otro desde hace mucho tiempo). Si intento la misma prueba en una máquina virtual CentOS con openssl 0.9.8e, entonces funciona bien, y puedo verlo leyendo el archivo del certificado strace. No hay acceso a archivos equivalente en el mismo punto en las capas de Ubuntu. Si copio el openssl.cnfarchivo de CentOS VM a las máquinas Ubuntu, no hay diferencia. No hay nada obvio en el entorno o un archivo .rc que pueda estar causando esto.

¿Alguna idea de lo que estoy haciendo mal? ¿Debería funcionar esto, es decir, openssl y curl recogen CA instaladas automáticamente desde la línea de comandos? ¿Cómo se configura esto? ¡Gracias!

Otro punto de datos: en una instalación limpia de 13 servidores, curlrecoge el archivo de certificados y funciona bien. openssl s_clientaunque todavía no. ¿Por qué sería eso?

Hay varias bibliotecas criptográficas en su sistema:

• OpenSSL (el estándar de oro, con una licencia de estilo BSD (muy gratuita) que incluye una cláusula algo problemática (que impide la compatibilidad GPL, pero nada "malo") que limita su adopción en el mundo GNU)
• GnuTLS (el reemplazo de la FSF; viene en dos versiones, con licencia LGPLv2 (pero sin mantenimiento) y con licencia LGPLv3 (y por lo tanto incompatible con los programas solo GPLv2); históricamente no es tan funcional como OpenSSL, un poco más defectuoso, pero más estricto también, lo que mejora la seguridad)
• NSS (biblioteca de Netscape / Mozilla, raramente utilizada en el exterior; lenta para adoptar nuevos estándares)
• los menores como PolarSSL, MatrixSSL, NaCl / Salt

Todos ellos tienen, por supuesto, similitudes y diferencias. El software que los usa (para fines criptográficos o para usar SSL / TLS) a veces admite el uso de más de una de estas bibliotecas (por ejemplo, Lynx, el navegador web, normalmente está vinculado a OpenSSL, pero también admite GnuTLS (solo que no es tan bueno) en para apaciguar a la gente de GNU).

cURL también es uno de los proyectos que admite el uso de cualquiera de las tres principales bibliotecas de cifrado. Esto se debe principalmente a que cURL es, principalmente, una biblioteca destinada a ser utilizada por otros programas cuando desean descargar (o incluso cargar) cosas usando conexiones http, ftp, etc. La curlherramienta de línea de comandos puede provenir de cualquiera de estas variantes.

Ahora, estoy bastante seguro de que el problema que está viendo con el sistema no recién instalado es el siguiente:

OpenSSL y GnuTLS admiten el uso de /etc/ssl/certs/<hash>.<number>directorios CA de estilo. Sin embargo, OpenSSL versión 0.xy GnuTLS usan un algoritmo diferente para calcular el hash mencionado anteriormente que el que usa OpenSSL versión 1.x. (Ambos pueden coexistir en un sistema; si diferentes certificados tienen el mismo hash , simplemente usa un número diferente para ellos. Pero por alguna razón, el ca-certificatespaquete Debian / Ubuntu no parece hacer esto). Además, algunas versiones de GnuTLS no admite el uso del directorio, pero solo el uso de un archivo /etc/ssl/certs/ca-certificates.crt(que generalmente también es administrado por los ca-certificatesscripts de mantenimiento del paquete, pero puede desviarse); parece que estás usando una versión anterior, por lo que esto puede ser lo que golpeas.

openssl s_clientde forma predeterminada (es decir, sin la opción -CApatho -CAfile) no busca certificados en ninguna parte .

Su curlde la instalación actualizada más probable es que utiliza una biblioteca de cifrado diferente a la curlde la instalación nueva.

Intente openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443además de openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443imitar el comportamiento de versiones anteriores de GnuTLS.

Vuelva a verificar si hay un OpenSSL 1.x en cualquier parte de su sistema (Ubuntu es conocido por infiltrar actualizaciones importantes incluso en versiones LTS), y si es así, verifique el hash del archivo:

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

Normalmente, el segundo y el tercer comando deberían fallar (OpenSSL 0.x), o el primer y tercer comando deberían mostrar el mismo hash pero el segundo debería mostrar un hash diferente (OpenSSL 1.x). GnuTLS usaría la salida del segundo comando (si está instalado OpenSSL 1.x); si OpenSSL 0.x está instalado, es el mismo hash. Puede crear dichos enlaces simbólicos manualmente.

Puedo actualizar esta publicación una vez que proporcione comentarios de depuración.