Hosted-by-discourse está usando certificados SSL caducados y la página de estado está en verde

Soporte
1

Esto está rompiendo nuestro sitio en este momento; parece que todas las publicaciones aquí se refieren a sitios autoalojados.

❯ openssl s_client -connect (removed).com:443 -servername (removed).com
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=(removed).com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

Los puntos finales de la API nos están devolviendo un error de certificado expirado, verificado mediante Postman.

2

@equipo, por favor ayuden aquí.

3

Hmm. Esto parece extraño.

4

Esto suena como un problema de tu lado (es decir, de tu sitio web).
El certificado proporcionado por el servidor es correcto y es aceptado por casi todos los navegadores; el problema es que muchos servidores más antiguos no tienen el certificado raíz (relativamente) nuevo en su almacén de confianza, por lo que muchas automatizaciones están generando errores en este momento.

No conozco tu sitio exacto, así que tomé un sitio arbitrario de hosted-by-discourse.com y lo sometí a la Prueba de servidor SSL de Qualys.

image
image854×760 37.7 KB

Puedes ver que la raíz de la segunda ruta de certificación está realmente expirada, pero esto se mitiga porque el certificado ISRG Root X1 está en el almacén de confianza (es decir, incluido en tu navegador y/o sistema operativo) para la primera ruta de certificación.

Los servidores generalmente no actualizan su almacén de confianza con frecuencia, por lo que es probable que tu servidor no tenga el certificado ISRG Root X1 en su almacén de confianza. (Esto es lo que también ocurrió con la imagen Docker de mail-receiver).

Puedes encontrar un bundle actualizado, por ejemplo, en https://curl.se/ca/cacert.pem. En CentOS, ese archivo se coloca en /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. En Ubuntu, puedes usar el comando update-ca-certificates, que actualiza /etc/ssl/certs/ca-certificates.crt.

Alternativamente, podrías deshabilitar temporalmente la verificación de certificados SSL en el código de tu servidor.

5

He publicado la salida de openssl para demostrar que no tiene nada que ver con nuestro sitio web; además, Postman se ejecuta desde una máquina local con Windows.

edición: no tengo tanto conocimiento sobre los diferentes niveles de almacenes de confianza, lo investigaré más. Esto ocurre simplemente en cada máquina que probamos.

6

¿No falla cuando usas un navegador real, verdad?

EDIT: Más personas tienen problemas con Postman, así que supongo que eso no es una prueba válida… :thinking:

7

esta es una respuesta que recibí de nuestro especialista en DevOps.

El problema es que existen dos copias de ISRG Root X1: una fue emitida por DST Root CA X3 hace mucho tiempo, y la más reciente fue autofirmada por la ISRG (el grupo que, entre otras cosas, gobierna Let’s Encrypt). Esa autoridad de certificación raíz autofirmada ahora es aceptada como una raíz de confianza en la mayoría de los sistemas.

Ambas son el mismo certificado de firma, por lo que puedes validar cualquier cosa que afirme haber sido emitida por «ISRG Root X1» con cualquiera de las dos versiones. Sin embargo, la versión firmada por DST ya no es válida como ruta de certificación, porque el certificado de DST que la firmó ha caducado.

Si el servidor estuviera actuando correctamente y proveyera la versión más reciente de ISRG Root X1 (la autofirmada), el cliente compararía el certificado proveydo con su propio almacén de confianza, verificaría que es el mismo certificado y todo funcionaría. Pero, en su lugar, al ver el certificado proveydo, el cliente piensa: «Ok, necesito validar esto contra DST Root CA X3 que tengo registrado… ¡ups, esa ha caducado!» y falla en la verificación.

8

Proveer un certificado en la cadena de certificados que se espera que esté en el almacén de CA raíz de confianza está muy lejos de “hacer lo correcto”.

Echemos un vistazo a la cadena de certificados del propio letsencrypt.org: SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

Miren, ¡hacen lo mismo! La cadena de certificados es idéntica (salvo, por supuesto, el certificado del servidor).

image
image812×744 33.1 KB

Así que o tu responsable de DevOps está equivocado, o CDCK, LetsEncrypt y Qualys están equivocados.
Dile que actualice el almacén de CA raíz. Eso resolverá el problema. Créeme.

9

Hola @bpaterson2000, lamentamos saber que tienes problemas para conectarte a nuestro servicio alojado. Como mencionó @RGJ, esto no es un problema de Discourse; debe solucionarse en tu cliente. (Nuestros servidores no «suministran» el certificado raíz; estos son gestionados por tu cliente).

Puedes encontrar más detalles sobre este cambio en Let’s Encrypt aquí:

10

Gracias por la información; se trata de un problema inesperado para nosotros, ya que los errores aparentemente provenían del servidor alojado.

Utilizamos Heroku, que empaqueta lo que mencionas a través de node/packages, al parecer. Parece que actualizar node fue la clave para volver a conectarlo con éxito a la API REST de Discourse.

Gracias por tu ayuda.