Certificados SSL/TLS — O Que Esses Campos e as Datatas de Vencimento Significam de fato

Em algum momento você já olhou para o pequeno cadeado no navegador, clicou em "Ver Certificado" e foi confrontado com uma parede de campos que parecem importantes mas não explicam nada: "Nomes Alternativos do Assunto", "OCSP", "SHA-256 com Criptografia RSA". Você fecha o diálogo. O certificado está verde. Isso é suficiente.

Até que expire. À meia-noite em uma sexta-feira. Em produção.

Este artigo descreve o que realmente está dentro de um certificado TLS — campo por campo — para que, na próxima vez que você precisar depurar um, saiba o que está lendo.

Um Certificado É Apenas um Documento Assinado

Remova a cerimônia e um certificado TLS é um documento de texto contendo algumas informações — quem possui esse domínio, qual chave pública eles usam, quando esse documento expira — que foi assinado criptograficamente por uma autoridade de certificados (CA). A assinatura da CA é o que faz os navegadores confiarem nele. Tudo o resto é anotação.

O formato subjacente é chamado X.509. Foi definido em 1988, revisado várias vezes e agora está especificado em RFC 5280. É por isso que os diálogos de detalhes de certificados nos navegadores parecem ter sido projetados por pessoas que consideram 1988 uma época recente.

Os Campos-Chave, Explicados

Aqui está uma análise detalhada dos campos que você verá em um certificado real. Os dados brutos PEM abaixo são representativos (não são um certificado ativo):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Nome Comum (CN)

O campo original para especificar qual domínio o certificado cobre. Você ainda verá esse campo preenchido — CN = example.com — mas os navegadores já pararam de depender dele. Desde 2000, a extensão de Nomes Alternativos do Assunto é o campo autorizado para correspondência de domínios. O CN está agora essencialmente como legado; se houver SAN, os navegadores usam apenas o SAN.

Nomes Alternativos do Assunto (SAN)

Este é a verdadeira lista de domínios que o certificado protege. Um único certificado pode cobrir dezenas de nomes — entradas com asterisco (*.example.com), nomes exatos, até endereços IP. Certificados multidomínio (também chamados de certificados SAN ou UCC) são prática comum. A autoridade de certificados emite contra essa lista e os navegadores correspondem o nome do host que você está visitando com ela.

Uma coisa que os asteriscos não pode fazem: cobrir sub-subdomínios. *.example.com abrange app.example.com mas não api.v2.example.com. Muitas pessoas descobrem isso de forma difícil.

Período de Validação

Dois timestamps: Antes de e Depois de. O certificado é inválido fora desse intervalo — antes da data de início, após a data de expiração. Ambos estão em UTC.

Os períodos máximos de validade dos certificados têm sido diminuindo gradualmente. Em 2015, o máximo era de 3 anos. Em 2018, caiu para 2 anos. Em 2020, a Apple começou unilateralmente a rejeitar certificados com mais de 398 dias (aproximadamente 13 meses), forçando os fabricantes de navegadores e as autoridades de certificados a seguir. Até 2026, o CA/Browser Forum ratificou um plano para reduzir isso a 47 dias até 2027.

A argumentação para períodos mais curtos é sólida: se uma chave privada for comprometida, um certificado de curta duração limita o alcance do impacto. A realidade operacional é que períodos mais curtos colocam mais pressão sobre a automação de renovação ser correta. Os certificados de 90 dias do Let’s Encrypt foram controversos em 2015 por essa mesma razão; hoje são considerados a prática recomendada e a renovação automatizada é esperada.

Emissor e a Cadeia de Confiança

O Emissor campo indica a entidade que assinou o certificado. Para a maioria dos sites públicos, é uma autoridade de certificados intermediária (como o R11 do Let’s Encrypt), e não uma autoridade de certificados raiz. As autoridades de certificados raiz assinam certificados de autoridades intermediárias; as autoridades intermediárias assinam certificados de entidades finais (os que seu servidor apresenta). Essa cadeia existe porque as chaves privadas das autoridades de certificados raiz são mantidas offline em HSMs isolados do ar, e você não pode expô-las para assinar milhões de certificados de domínio por ano.

Quando um navegador valida seu certificado, ele percorre a cadeia: seu certificado → intermediário → raiz. Se a raiz estiver no repositório de confiança do navegador, a cadeia será validada. Se qualquer certificado na cadeia estiver faltando, expirado ou assinado com uma chave revogada, a validação falhará.

É por isso que a configuração mais comum de TLS é esquecer de servir o certificado intermediário junto com seu certificado de folha. O navegador pode armazenar o intermediário e parecer tudo bem, enquanto outros clientes — curl, aplicativos móveis, servidores fazendo chamadas de API — falham porque não têm um caminho até a raiz.

Algoritmo de Assinatura

Dois elementos combinados em um campo: a função de hash usada para digerir os dados do certificado e o algoritmo de chave usado para assinar essa digerção. sha256WithRSAEncryption significa hash SHA-256, assinatura RSA. ecdsa-with-SHA256 significa hash SHA-256, assinatura ECDSA.

As assinaturas SHA-1 foram descontinuadas pelos navegadores em 2017 e agora causam falhas duras. As assinaturas MD5 foram descontinuadas anteriormente e estão praticamente extintas. Se você estiver executando algo que emite certificados SHA-1 internamente, atualize a configuração da sua CA antes que uma atualização do navegador faça isso por você.

As assinaturas ECDSA (geralmente P-256 ou P-384) produzem chaves e assinaturas menores do que o RSA para a mesma segurança. Uma chave EC de 256 bits é aproximadamente equivalente a uma chave RSA de 3072 bits. A troca: o RSA é mais compatível com clientes muito antigos; a ECDSA é mais rápida e leve. As implementações modernas muitas vezes configuram ambas e deixam que o negociação TLS escolha.

Uso da Chave e Uso Estendido da Chave

Uso da Chave é um bitmáscara especificando o que a chave é permitida a fazer: assinar dados, criptografar dados, assinar outros certificados (apenas para autoridades de certificados). Uso Estendido da Chave refina isso para protocolos específicos: TLS Web Server Authentication é o que permite o uso do certificado para HTTPS. TLS Web Client Authentication é para certificados de clientes mTLS. Code Signing é para certificados de assinatura de software.

Se você tentar usar um certificado para um propósito fora do seu uso declarado de Chave, as implementações modernas de TLS o recusarão. Você não pode usar um certificado de assinatura de código em um servidor web, mesmo que o domínio corresponda.

Restrições Básicas: CA:FALSE

Este campo especifica se o certificado pode ser usado para assinar outros certificados. CA:FALSE significa que não pode — é um certificado de folha (final de entidade). CA:TRUE significa que é um certificado de autoridade, permitido para assinar outros certificados na cadeia.

O pathLenConstraint que às vezes aparece ao lado disso informa quantas autoridades intermediárias abaixo desse nível são permitidas. As autoridades de certificados raiz frequentemente definem isso para limitar a profundidade da cadeia.

OCSP e Revogação

A URL do OCSP (Protocolo de Status de Certificados Online) no certificado informa aos clientes onde verificar se o certificado foi revogado antes de expirar. A revogação ocorre quando uma chave privada é comprometida ou o certificado foi emitido por erro.

Na prática, a verificação de OCSP pelos navegadores tem uma história complicada. O Chrome parou de fazer verificações de OCSP em tempo real há anos, preferindo CRLSets (uma lista pré-carregada de certificados revogados de alto valor). O Firefox ainda faz OCSP, mas defaulta para falha suave, o que significa que, se o servidor OCSP não for acessível, o certificado é tratado como válido. O efeito geral: para a maioria dos certificados, a revogação no mundo real é quase teórica. Isso é um dos argumentos para certificados de curta duração — em 47 dias, a revogação importa menos porque o certificado expira logo.

Por que os Certificados Expiram

A expiração não é uma fricção burocrática. É o mecanismo que limita por quanto tempo um credencial comprometido permanece válido. A alternativa — credenciais permanentes — é como você acaba tendo certificados SHA-1 e chaves de autoridades de certificados de décadas flutuando em produção, o que era basicamente o estado da indústria em 2010.

A trade-off é operacional: períodos mais curtos exigem automação confiável. Se sua renovação depender de um lembrete de calendário de um administrador de sistema, você expirará em produção eventualmente. A resposta correta é a renovação automatizada via ACME (o protocolo do Let’s Encrypt) ou a API da sua CA, com monitoramento que alerta várias semanas antes da expiração, e não a noite em que ele morre.

Como Ler um Certificado Sem Linha de Comando

A forma padrão de inspecionar um certificado é openssl x509 -in cert.pem -text -noout, que produz saída formatada para pessoas que acham a leitura do RFC 5280 leve. Se você quiser a mesma informação em um formato que não exige memorizar flags do openssl, o Decodificador de Certificados SSL/TLS e Analisador de Certificados X.509 no iotools.cloud ambos recebem um certificado em formato PEM e retornam todos os campos rotulados e organizados — útil quando você está debugando um problema de cadeia às meias-noites e o texto extenso do openssl não está ajudando.

Você também pode gostar