SSL/TLS
Monitorização de certificados SSL/TLS
O certificado SSL/TLS que um host serve e quantos dias faltam até expirar.
Experimenta agora
Uma verificação, de um lugar, agora mesmo, e nada é guardado. Um monitor verifica de todas as localizações onde operamos e confirma uma falha a partir de dois outros continentes antes de alguém ser acordado, algo que uma única verificação não pode mostrar.
Para que serve
A expiração de certificados é a falha que todos já tiveram e ninguém planeia. A renovação é automatizada até ao dia em que a automação falha silenciosamente, e o primeiro sinal é todos os navegadores do mundo recusarem o teu site de uma vez com NET::ERR_CERT_DATE_INVALID.
Isto abre uma conexão TLS na porta 443, ou onde tu indicares, e lê o certificado X.509 que o host está realmente a servir. Nem sempre é o mesmo que o teu processo de renovação escreveu: um load balancer com um nó desatualizado, um segundo host virtual que ninguém recarregou, uma CDN a segurar a cadeia antiga. Relata o subject, a autoridade certificadora emissora e a data notAfter, para uma contagem decrescente em vez de um estado de ativo ou inativo.
Certificados wildcard e SAN são um único certificado, então monitoriza o host de onde cada um é realmente servido. Um certificado que cobre *.example.com em três load balancers são três monitores, porque o problema que ocorre é um dos três não ser recarregado.
Como cada verificação aqui, corre a partir de Amsterdam, New York, Sydney and Singapore, e uma falha é confirmada a partir de dois outros continentes antes de alguém ser acordado. Como funciona isso.
O que podes configurar
Tudo abaixo está no formulário quando adicionas um, em todos os planos.
- Host
- Um hostname, um host e porta, ou um URL: example.com, example.com:8443 e https://example.com funcionam todos. Porta 443, a menos que indiques outra.
Recebes três avisos: aos catorze dias, sete dias e dois dias, cada um enviado uma vez. Lembretes diários são ignorados, por isso não se repetem. Trinta dias é ignorado de propósito: é quando o Let's Encrypt renova, então dispararia em todos os certificados saudáveis. Se o certificado expirou ou não conseguimos lê-lo de todo (conexão recusada, falha no handshake, nada responde), isso é um alerta, não um aviso, e dispara no momento em que o vemos.
Perguntas
Qual é a diferença entre um certificado SSL e um certificado TLS?
Nada, para este propósito. SSL é o nome antigo do protocolo, TLS é o atual, e SSL 2.0 e 3.0 estão mortos há mais de uma década. O ficheiro em si é um certificado X.509 de qualquer forma, e não sabe qual protocolo o apresentará. A maioria das pessoas ainda procura por SSL, então escrevemos SSL/TLS e queremos dizer o mesmo que tu.
Por que é que o meu navegador diz NET::ERR_CERT_DATE_INVALID?
O certificado entregue ao navegador expirou ou a sua data notBefore ainda não chegou, o que acontece quando o relógio do servidor está errado. O Chrome mostra este código, o Firefox diz SEC_ERROR_EXPIRED_CERTIFICATE e o Safari diz que o certificado não é válido. Este monitor é o que te avisa dois dias antes dos teus visitantes.
Isto verifica a cadeia de certificados?
Esta verificação lê a expiração, então uma cadeia incompleta ou um certificado intermediário em falta não a faz falhar. Um monitor HTTPS verifica a cadeia: conecta-se como um navegador e falha numa cadeia inválida, num certificado autoassinado ou numa incompatibilidade de hostname. Usa ambos em tudo o que importa, por isso o HTTPS está em todos os planos.
E os certificados wildcard e SAN?
Ambos funcionam. Um certificado wildcard, ou um com vários subject alternative names, é um único certificado com uma única data de expiração. O que varia é qual host está a servi-lo, então adiciona um monitor por host em vez de um por nome no certificado.
Verificas OCSP ou transparência de certificados?
Não, e dizemos isso em vez de sugerir o contrário. Isto lê o certificado que um host serve e relata os dias restantes. Verificação de revogação e monitorização de logs CT são produtos diferentes que resolvem problemas diferentes, e um monitor que fizesse metade seria pior do que um que não faz.
A minha renovação é automatizada. Ainda preciso disto?
É exatamente para isso que isto serve. Ninguém com uma renovação manual se esquece por noventa dias seguidos; as falhas vêm de uma renovação do Let's Encrypt que falhou silenciosamente há seis semanas ou que teve sucesso na máquina que escreve o certificado e não na que o serve.
E se o host não responder de todo?
Uma falha no handshake TLS, uma conexão recusada ou um timeout são relatados como uma falha na verificação em vez de um aviso de expiração, porque são problemas diferentes com soluções diferentes. A contagem decrescente de expiração só avança quando realmente lemos um certificado.
Por que não colocar apenas a data de renovação num calendário?
Um lembrete não custa nada e é melhor do que nada, então coloca um também. O problema é que a data no teu calendário é uma data que alguém escreveu, e o certificado no servidor é o que está realmente lá. Eles concordam até uma renovação ter sucesso parcial, um deploy enviar um bundle antigo, um host num pool perder o novo ficheiro ou o certificado renovado não ser o que está a ser servido. Isto lê o certificado da mesma forma que um visitante o recebe, então a data que avisa é a real.