SSL/TLS
Monitoreo de certificados SSL/TLS
El certificado SSL/TLS que un host sirve y cuántos días le quedan antes de que expire.
Pruébalo ahora
Una comprobación, desde un lugar, ahora mismo, y nada se guarda. Un monitor verifica desde cada ubicación en la que operamos y confirma un fallo desde otros dos continentes antes de que alguien sea despertado, lo cual una sola mirada no puede mostrarte.
Para qué sirve
La expiración de certificados es el fallo que todos han tenido y nadie planea. La renovación es automática hasta el día en que la automatización falla silenciosamente, y el primer signo es que todos los navegadores del mundo rechazan tu sitio de golpe con NET::ERR_CERT_DATE_INVALID.
Esto abre una conexión TLS en el puerto 443, o donde tú digas, y lee el certificado X.509 que el host realmente está sirviendo. No siempre es el que tu tarea de renovación escribió: un balanceador de carga con un nodo obsoleto, un segundo host virtual que nadie recargó, un CDN con la cadena antigua. Reporta el subject, la autoridad emisora del certificado y la fecha notAfter, así que es una cuenta regresiva en lugar de un estado de activo o inactivo.
Los certificados wildcard y SAN son un solo certificado, así que vigila el host desde el que realmente se sirve cada uno. Un certificado que cubre *.example.com en tres balanceadores de carga son tres monitores, porque lo que falla es que uno de los tres no se recargue.
Como cada chequeo aquí, se ejecuta desde Amsterdam, New York, Sydney and Singapore, y un fallo se confirma desde otros dos continentes antes de despertar a nadie. Cómo funciona.
Lo que puedes configurar
Todo lo siguiente está en el formulario cuando añades uno, en todos los planes.
- Host
- Un nombre de host, un host y puerto, o una URL: example.com, example.com:8443 y https://example.com funcionan. Puerto 443 a menos que indiques otro.
Recibes tres avisos: a catorce días, siete días y dos días, cada uno enviado una vez. Los recordatorios diarios se ignoran, así que no se repiten. Treinta días se omiten a propósito: es cuando Let's Encrypt renueva, así que dispararía en cada certificado saludable. Si el certificado ha expirado o no podemos leerlo en absoluto (conexión rechazada, fallo en el handshake, nada responde), eso es una alerta, no un aviso, y se dispara en el momento en que lo vemos.
Preguntas
¿Cuál es la diferencia entre un certificado SSL y un certificado TLS?
Nada, para este propósito. SSL es el nombre antiguo del protocolo, TLS es el actual, y SSL 2.0 y 3.0 llevan muertos más de una década. El archivo en sí es un certificado X.509 de cualquier manera, y no sabe qué protocolo lo presentará. La mayoría aún busca por SSL, así que escribimos SSL/TLS y queremos decir lo mismo que tú.
¿Por qué mi navegador dice NET::ERR_CERT_DATE_INVALID?
El certificado que el navegador recibió ha expirado, o su fecha notBefore aún no ha llegado, lo que pasa cuando el reloj del servidor está mal. Chrome muestra este código, Firefox dice SEC_ERROR_EXPIRED_CERTIFICATE y Safari dice que el certificado no es válido. Este monitor es lo que te avisa dos días antes de que lo hagan tus visitantes.
¿Esto verifica la cadena del certificado?
Esta verificación lee la expiración, así que una cadena incompleta o un certificado intermedio faltante no la falla. Un monitor HTTPS sí verifica la cadena: conecta como lo hace un navegador y falla con una cadena inválida, un certificado autofirmado o un nombre de host que no coincide. Usa ambos en todo lo que importe, por eso HTTPS está en todos los planes.
¿Qué pasa con los certificados wildcard y SAN?
Ambos funcionan. Un certificado wildcard, o uno con varios nombres alternativos de sujeto, es un solo certificado con una sola fecha de expiración. Lo que varía es qué host lo está sirviendo, así que añade un monitor por host en lugar de uno por nombre en el certificado.
¿Verificáis OCSP o la transparencia de certificados?
No, y lo decimos en lugar de implicar lo contrario. Esto lee el certificado que un host sirve y reporta los días restantes. La verificación de revocación y el monitoreo de logs de CT son productos diferentes que resuelven problemas diferentes, y un monitor que los hiciera a medias sería peor que uno que no los hace.
Mi renovación es automática. ¿Aún necesito esto?
Eso es exactamente para quien es esto. Nadie con una renovación manual olvida durante noventa días seguidos; los fallos vienen de una renovación de Let's Encrypt que falló silenciosamente hace seis semanas, o que tuvo éxito en la máquina que escribe el certificado y no en la que lo sirve.
¿Qué pasa si el host no responde en absoluto?
Un fallo en el handshake TLS, una conexión rechazada o un timeout se reporta como un fallo de la verificación en lugar de como un aviso de expiración, porque son problemas diferentes con soluciones diferentes. La cuenta regresiva de expiración solo avanza cuando realmente leemos un certificado.
¿Por qué no simplemente poner la fecha de renovación en un calendario?
Un recordatorio no cuesta nada y es mejor que nada, así que pon uno también. El problema es que la fecha en tu calendario es una fecha que alguien escribió, y el certificado en el servidor es lo que realmente está ahí. Coinciden hasta que una renovación tiene éxito a medias, un deploy envía un paquete antiguo, un host en un pool pierde el archivo nuevo, o el certificado que se renovó no es el que se está sirviendo. Esto lee el certificado como lo recibe un visitante, así que la fecha sobre la que avisa es la real.