Mantenga HTTPS funcionando durante todo el ciclo de vida del certificado
Que un navegador muestre hoy una conexión segura es el comienzo de las operaciones con certificados, no el final. Un dominio puede cambiar de ubicación, una ruta de validación puede cambiar o una renovación puede completarse sin que el servicio público cargue el nuevo certificado. Trate la emisión, el despliegue y la verificación continua como pasos separados con un responsable claro.
La conclusión práctica
Conozca todos los puntos de terminación de TLS, automatice la renovación con el método de validación adecuado, pruebe ese proceso y verifique el certificado que realmente se sirve a los usuarios tras el despliegue.
Determine dónde termina la conexión segura
Enumere los nombres de host que los usuarios visitan realmente, incluidos el dominio principal, cualquier nombre www, los subdominios de aplicaciones y los endpoints importantes de API. Después, identifique dónde termina TLS para cada uno: un servidor web, un proxy inverso, un balanceador de carga u otro servicio gestionado. Un certificado instalado en el origen no demuestra que un proxy público independiente sirva el mismo. Mantenga este inventario junto con las personas responsables de los dominios y del acceso al alojamiento.
Un certificado debe cubrir el nombre de host solicitado por el cliente y encadenar hasta un ancla de confianza que ese cliente acepte. El servicio también debe presentar correctamente el certificado correspondiente y la cadena intermedia. Compruebe más de una URL cómoda cuando las aplicaciones usen varios nombres. Una conexión correcta al dominio sin prefijo dice poco sobre un subdominio de API o un servicio de correo independiente, que pueden tener su propio proceso de certificados.
HTTPS protege la conexión según el protocolo y la configuración aplicables; no es prueba de que la aplicación no tenga vulnerabilidades ni de que un comerciante sea fiable. Mantenga el control de acceso, las actualizaciones y las copias de seguridad en su propio plan operativo. La lista de funciones de alojamiento web de HM Bastion incluye la renovación automatizada de SSL, mientras que un administrador de VPS debe confirmar y gestionar las herramientas de certificados usadas en su propia pila. No dé por hecho que esas responsabilidades son idénticas.
Elija la validación según el entorno que ejecuta
ACME automatiza las interacciones necesarias para obtener certificados, incluida la prueba de control de los nombres de dominio solicitados. Distintos métodos de desafío encajan en distintos entornos. La validación basada en HTTP depende de que la ruta de validación requerida sea accesible tal como especifica la autoridad de certificación. La validación basada en DNS depende del control de los registros DNS correspondientes. Lea la documentación de la autoridad y del cliente antes de elegir un método, especialmente cuando haya un proxy o varias instancias de aplicación delante del origen.
| Pregunta operativa | Qué debe establecerse |
|---|---|
| ¿Quién controla DNS? | Un responsable identificado y el acceso de validación necesario |
| ¿Dónde pueden llegar las solicitudes de validación? | El enrutamiento público y la gestión de desafíos para cada nombre relevante |
| ¿Cómo se almacenan las credenciales? | Almacenamiento privado y los permisos más restringidos disponibles |
| ¿Qué ocurre tras la emisión? | Despliegue al servicio correcto y recarga verificada |
La automatización de DNS puede requerir credenciales con un poder considerable sobre un dominio. Guárdelas fuera de los directorios públicos y concédales solo los permisos que necesite la integración elegida, cuando sea compatible. Separe la documentación del proceso de los valores secretos reales. La validación manual puede ser adecuada para una configuración concreta, pero crea una dependencia humana recurrente; anote quién la completará y cómo se detectará una renovación próxima.
Use el entorno de pruebas de la autoridad de certificación al probar una integración, cuando esté disponible. Permite ejercitar el proceso sin tratar la emisión repetida en producción como método de depuración. Un certificado de pruebas no es de confianza para el servicio público normal, así que mantenga claro el propósito de la prueba. Evite dar por sentados de forma fija los periodos de validez de los certificados o los calendarios de renovación cuando la autoridad y el cliente ofrezcan indicaciones o información de renovación que puedan cambiar.
Renovación, despliegue y recarga son resultados distintos
Compruebe que el mecanismo de renovación programado se ejecuta realmente con la cuenta y el entorno previstos. Un comando que funciona en una terminal interactiva puede depender de una ruta, un permiso o una credencial ausentes en su ejecución programada. Revise los registros correspondientes y use el procedimiento de prueba de renovación compatible con el cliente. Para Certbot, la documentación describe las pruebas en seco y los hooks de renovación; siga las instrucciones adecuadas a la versión instalada y al autenticador elegido.
Un archivo de certificado recién generado no cambia automáticamente lo que presenta un servicio en ejecución. El servicio puede necesitar una recarga, un enlace de despliegue o su distribución a varios puntos de terminación. Valide la configuración antes de recargar, conserve una vía de reversión y compruebe la conexión pública después. En una configuración con varios nodos, una única solicitud correcta puede llegar solo a un nodo. Planifique una comprobación que abarque el despliegue real en lugar de suponer que todas las instancias cambiaron a la vez.
Supervise el certificado que se sirve externamente, los nombres que cubre y el tiempo restante antes de su caducidad. Esto detecta un fallo distinto de supervisar si la tarea de renovación finalizó correctamente. Mantenga actualizados los responsables de las notificaciones, incluso cuando cambie una agencia o un administrador. Una alerta enviada a un buzón abandonado ofrece poca protección. Revise el inventario tras cambiar DNS, añadir un proxy inverso, mover un nombre de host o modificar la configuración del servidor web.
Investigue una renovación fallida desde el paso que falló
- Registre el nombre de host afectado, la versión del cliente, la hora y el error exacto sin datos secretos.
- Determine si el fallo es de validación, emisión, despliegue o servicio público.
- Compruebe el DNS, el enrutamiento, el acceso a archivos y el entorno de las tareas programadas correspondientes.
- Corrija y pruebe la causa concreta antes de reintentar la emisión en producción.
- Verifique el certificado público y los recorridos normales de la aplicación tras la recuperación.
Por ejemplo, si la validación falla tras un cambio de DNS, compare los registros públicos actuales con la ruta de desafío prevista antes de sustituir las herramientas de certificados. Si la emisión se realiza correctamente pero el navegador sigue viendo un certificado antiguo, inspeccione el punto de terminación público y el proceso de despliegue. Solicitar certificados repetidamente no solucionará un proxy que lee otro archivo. Conserve el error original y las acciones posteriores en una cronología para que la siguiente persona pueda seguir el diagnóstico.
Si una clave privada puede haberse expuesto, trátelo como un incidente de seguridad y no como un simple recordatorio de caducidad. La respuesta puede incluir la sustitución de claves, la revocación de los certificados afectados mediante el proceso adecuado y la investigación de la exposición. Nunca incluya una clave privada ni una credencial de DNS en un ticket de soporte. Comparta el nombre de host, los identificadores de certificado cuando sea útil y la salida de diagnóstico segura para que el equipo pueda investigar sin recibir el control del dominio.
