Validação de certificados no TLS

Sem a validação de certificados, uma conexão TLS poderia ser estabelecida com um invasor que se passasse pelo servidor (um intermediário malicioso). A validação garante que você está se comunicando com o servidor legítimo que controla a chave privada.

Campos principais: titular (quem possui o certificado), SubjectAltName (nomes DNS e endereços IP), emissor (CA que assina), validade (notBefore/notAfter), chave pública e assinatura. O navegador verifica todos eles.

Certificado do servidor → certificado da CA intermediária → certificado da CA raiz. A CA raiz é autoassinada e vem pré-instalada no armazenamento de confiança do OS/navegador. O servidor envia seu certificado e os certificados intermediários na mensagem de certificado da negociação TLS.

Cada certificado é assinado pelo emissor acima dele. O cliente verifica: signature(cert_n) usando public_key(cert_{n+1}). Se alguma assinatura for inválida, a cadeia será rejeitada. A raiz é confiável por estar pré-instalada, não por sua assinatura.

O cliente verifica se o nome do host do servidor corresponde ao titular do certificado ou ao SubjectAltName (entradas DNS). Os curingas (*.example.com) correspondem a um único rótulo. Desde 2000, SAN tem precedência sobre CN na correspondência de nomes de host.

O cliente verifica notBefore ≤ agora ≤ notAfter em todos os certificados da cadeia. Certificados expirados são rejeitados mesmo quando as assinaturas são válidas. A duração dos certificados diminuiu: os navegadores agora a limitam a cerca de 398 dias.

A CA publica uma Lista de Revogação de Certificados (CRL) — uma lista assinada dos números de série dos certificados revogados. O cliente baixa o endereço da CRL (da extensão de pontos de distribuição da CRL do certificado) e verifica se o número de série está presente.

O Protocolo de Status de Certificados Online (OCSP) permite que os clientes consultem o respondedor OCSP da CA sobre o status de um único certificado. É mais rápido que uma CRL, mas acrescenta latência. A anexação de OCSP faz com que o servidor inclua uma resposta OCSP assinada na negociação TLS.

O CT (RFC 6962) exige que as CAs registrem todos os certificados emitidos em registros públicos que aceitam apenas acréscimos. Os navegadores verificam a presença de marcas de tempo de certificados assinadas nos certificados ou na extensão TLS. Isso impede que emissões indevidas passem despercebidas.

A fixação de chaves públicas HTTP (HPKP, obsoleta) e a fixação de certificados em aplicativos móveis vinculam uma chave pública específica ou um resumo criptográfico específico do certificado. Se o servidor apresentar um certificado diferente, a conexão será rejeitada mesmo que ele seja válido — isso impede ataques de comprometimento da CA.

ERR_CERT_AUTHORITY_INVALID: raiz não confiável. ERR_CERT_DATE_INVALID: certificado expirado. ERR_CERT_COMMON_NAME_INVALID: nome do host incompatível. NET::ERR_CERT_REVOKED: OCSP/CRL informa que o certificado foi revogado. Cada erro corresponde à falha de uma etapa específica da validação.

O que a anexação de OCSP proporciona?

A validação de certificados no TLS envolve verificação da cadeia, verificação de assinaturas, correspondência de nomes, períodos de validade e revogação. A seguir: ataques históricos ao TLS e como o TLS 1.3 os mitiga.