Mi certificado SSL tenía que ser renovado y en principio es una tarea simple. Bajar el certificado root, el intermedio, crear un bundle y configurar Nginx.
Pero esta vez pasó algo. Descargo los certificados y claves, cambio la configuración de Nginx apuntando a los nuevos ficheros.
Lanzo el despliegue, Nginx me dice que “ok” porque en el entorno de beta me funciona bien y veo la web y en el entorno de prod se despliega también correctamente.
Pero acto seguido empiezo a tener avisos de caída del blog y al acceder veo error 502 desde CloudFront. Algo parecido a esto.
¿Pero por qué si en beta el Nginx ha cargado bien los nuevos certificados?
En este caso, dado que había habido una renovación del certificado SSL de por medio era claro que el problema venía por allí. Mi confusión era que, normalmente, si hay un problema, Nginx ni levanta.
No fue así en este caso.
AWS tiene algunas páginas dedicadas a este problema:
- https://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html
- https://aws.amazon.com/es/premiumsupport/knowledge-center/cloudfront-502-errors/
Verificando estado del certificado con OpenSSL
Leyendo la documentación que hay en AWS, hay una serie de comandos que podemos usar para validar el correcto estado de nuestro certificado configurado con Nginx o otro servidor web.
En concreto, la parte que dice “El certificado SSL no coincide con el nombre de dominio” usa el comando
# openssl s_client -connect DOMAIN:443 -servername SERVER_DOMAIN | openssl x509 -text | grep -E '(CN|Alternative)' -A 2
en mi caso, el problema no era el nombre del dominio pero usando este comando pude ver la raíz del problema:
# openssl s_client -connect localhost:443 -servername www.rubenortiz.es | openssl x509 -text | grep -E '(CN|Alternative)' -A 2
depth=0 CN = www.rubenortiz.es
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.rubenortiz.es
verify error:num=21:unable to verify the first certificate
verify return:1“Unable to get local issuer certificate”
Mi reacción:
El problema fue básicamente una mala configuración del certificado SSL. Al crear el “bundle” de alguna forma me dejé algo por el camino, pero no fue suficiente como para bloquear al servicio de Nginx. Si hubiera roto el servicio esto me hubiera dado problemas ya en beta.
Una vez detectado el problema, volví a ejecutar el comando openssl. Y el output ya era diferente.
# openssl s_client -connect 0.0.0.0:443 -servername www.rubenortiz.es | openssl x509 -text | grep -E '(CN|Alternative)' -A 2
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = www.rubenortiz.es
verify return:1
Como bonus, si queremos comprobar insitu la caducidad del certificado podemos usar este comando openssl
# openssl s_client -connect 0.0.0.0:443 -servername www.rubenortiz.es | openssl x509 -text | grep Validity -A 3
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = www.rubenortiz.es
verify return:1
Validity
Not Before: Feb 3 00:00:00 2023 GMT
Not After : Mar 4 23:59:59 2024 GMT
Subject: CN=www.rubenortiz.es
