acme.sh renovó el certificado, pero Nginx sigue sirviendo el anterior

1. Localizar la entrada del certificado que se renueva

Lista los certificados y examina la entrada correspondiente. Sustituye example.com por el nombre principal del certificado. Los ejemplos con --ecc seleccionan un certificado ECC; omite esa opción de los comandos para una entrada RSA. Si utilizas rutas personalizadas para --home, --config-home o --cert-home, consérvalas en cada comando para consultar la instalación correcta.

"$HOME/.acme.sh/acme.sh" --list
"$HOME/.acme.sh/acme.sh" --info -d example.com --ecc

Revisa Le_RealKeyPath, Le_RealFullChainPath y Le_ReloadCmd, junto con los datos de emisión y renovación. Mantén esta salida privada: la configuración y los comandos pueden contener valores sensibles. Comprueba la cuenta, la programación y los registros de la tarea de renovación. Un fallo de emisión necesita su propio diagnóstico; un certificado nuevo válido con un error de instalación no justifica forzar renovaciones repetidas.

2. Comparar los destinos con las rutas de Nginx

Usa archivos de destino dedicados para Nginx. El directorio de trabajo interno de acme.sh no es una interfaz de despliegue estable. Revisa las rutas de la configuración activa y los montajes de contenedores, si los hay. Este fragmento pertenece a un bloque de servidor HTTPS existente.

ssl_certificate     /etc/nginx/tls/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/tls/example.com/key.pem;

Lee el certificado público en el destino configurado y anota su huella SHA-256, fechas de validez y SAN. La cadena completa debe contener primero el certificado del servidor, seguido de los certificados intermedios.

openssl x509 -in /etc/nginx/tls/example.com/fullchain.pem \
  -noout -sha256 -fingerprint -issuer -dates -ext subjectAltName

Que el archivo interno de acme.sh esté actualizado no demuestra que el destino se haya actualizado. Que el destino esté actualizado tampoco demuestra que Nginx lo haya cargado. Mantén la clave privada confidencial y comprueba que el proceso que la carga tenga los permisos necesarios.

3. Guardar las rutas correctas y el comando de recarga

El siguiente comando modifica los archivos inmediatamente y recarga Nginx. Úsalo tras comprobar los destinos y la entrada del certificado. Prepara el directorio de destino con el propietario y los permisos adecuados. La cuenta que ejecuta acme.sh debe poder escribir esos archivos y ejecutar la recarga sin intervención.

"$HOME/.acme.sh/acme.sh" --install-cert -d example.com --ecc \
  --key-file /etc/nginx/tls/example.com/key.pem \
  --fullchain-file /etc/nginx/tls/example.com/fullchain.pem \
  --reloadcmd "/usr/sbin/nginx -t && /usr/bin/systemctl reload nginx"

Adapta las rutas absolutas de los ejecutables y la unidad de systemd. El && impide la recarga si nginx -t falla. acme.sh guarda los destinos y el comando para futuras renovaciones. Se conservan el propietario y los permisos de los archivos de destino existentes. Comprueba el código de salida y los registros: un fallo de recarga puede dejar los archivos nuevos en disco mientras se sigue sirviendo el certificado anterior. Corrige la causa y repite --install-cert con los parámetros previstos. En contenedores, el comando debe llegar al proceso Nginx correspondiente, no a un servicio del mismo nombre en el host.

4. Verificar el certificado recibido por TLS

Desde fuera de la red de alojamiento, abre una nueva conexión TLS hacia un servicio que administres o tengas permiso para inspeccionar. Conserva el nombre de host como SNI y compara la huella con el archivo de destino. Esta prueba muestra el certificado; no valida la confianza en la cadena ni la correspondencia del nombre de host.

set -o pipefail
timeout 10 openssl s_client -connect example.com:443 \
  -servername example.com </dev/null |
  openssl x509 -noout -sha256 -fingerprint \
    -issuer -dates -ext subjectAltName

Si las huellas difieren, identifica el componente que termina TLS. Un CDN o balanceador puede servir su propio certificado. Comprueba las direcciones públicas y las rutas hacia el origen pertinentes; usa IP:443 o [IPv6]:443 con -connect y conserva el nombre de host en -servername. Varias réplicas o certificados RSA/ECDSA pueden producir observaciones distintas. Si se sirve el certificado esperado pero el navegador lo rechaza, revisa la cadena y los nombres cubiertos.

5. Reproducir un fallo de recarga localmente

El script ejecuta el comando real acme.sh --install-cert con certificados autofirmados temporales de prueba. Nginx sirve inicialmente el certificado anterior. Un comando de recarga que falla de forma deliberada permite que acme.sh copie los archivos nuevos, pero devuelve un error. Una segunda instalación con un comando de recarga correcto hace que Nginx sirva el nuevo certificado.

Descargar y revisar la demostración de acme.sh

Requisitos: Linux, Bash, un motor Docker local, curl, OpenSSL y GNU coreutils. El script descarga una versión fija de acme.sh, verifica su suma de comprobación y usa una imagen de Nginx fijada por digest. Léelo y ejecuta bash acme-sh-install-reload.sh.

BEFORE y SERVED muestran la huella anterior; DISK muestra la nueva; AFTER debe coincidir con DISK. Las aserciones también comprueban las rutas y el comando guardados, así como la conservación de los permisos del archivo de clave. El script usa un directorio temporal de acme.sh y un puerto de loopback, y elimina su contenedor y sus archivos temporales al salir. No instala ninguna tarea cron. La imagen Docker permanece en caché.

Solo esta prueba, ligada a una versión concreta, prepara el estado interno de acme.sh con archivos sintéticos. No reproduzcas esa preparación en un almacén real de certificados. La demostración verifica la instalación, la gestión de errores y la recarga, no la emisión ACME, la programación de renovaciones ni la confianza de los navegadores públicos.

6. Mantener la vigilancia tras la comprobación inmediata

Anota la dirección, el SNI, la hora y la huella observados tras el despliegue. Confirma que la tarea de renovación use las mismas rutas y disponga de permisos suficientes sin una shell interactiva. Registra sus fallos en la supervisión de tareas que ya utilizas.

Nocert observa periódicamente los certificados servidos por los puntos de terminación TLS accesibles y evalúa las reglas de aviso de caducidad en un ciclo diario. Comprueba el punto de terminación y la hora de observación, y configura los destinatarios. Este seguimiento complementa la prueba externa inmediata. Nocert no ejecuta acme.sh, no instala certificados ni recarga Nginx, y no garantiza que todos los visitantes reciban el mismo certificado.