Ciclo de vida e revogação de certificados

Todo certificado digital segue um ciclo de vida definido, desde a criação até a aposentadoria. As etapas são: solicitação e inscrição (gerar o par de chaves, criar a CSR), emissão (a CA valida e assina), implantação (instalar no servidor ou dispositivo), uso (período operacional ativo), renovação (antes da expiração) e revogação ou expiração (fim da vida útil). Gerenciar esse ciclo de vida em escala — especialmente em empresas com milhares de certificados — exige automação e ferramentas de gerenciamento do ciclo de vida de certificados (CLM), pois o acompanhamento manual inevitavelmente leva a certificados expirados que causam interrupções.

O ciclo de vida do certificado começa com um Certificate Signing Request (CSR). O solicitante gera um par de chaves e, em seguida, cria uma CSR que contém a chave pública, as informações do Subject (CN, O, C) e é assinada com a chave privada (comprovando a posse da chave privada sem revelá-la). A CSR é enviada à CA, que valida a identidade do solicitante e, se aprovada, assina o certificado. A chave privada nunca sai da posse do solicitante. A geração da CSR é a etapa crítica em que a força da chave é determinada — use no mínimo RSA de 2048 bits ou ECC de 256 bits.

Os certificados precisam ser renovados antes que sua data notAfter expire. A prática recomendada é iniciar o processo de renovação pelo menos 30 dias antes da expiração (muitas organizações têm como meta 60 a 90 dias). A renovação normalmente envolve gerar uma nova CSR e uma nova chave privada, enviá-las à CA e substituir o certificado e a chave antigos em todos os servidores nos quais estão implantados. A Let's Encrypt automatiza esse processo usando o protocolo ACME — a ferramenta certbot renova automaticamente os certificados quando faltam menos de 30 dias para a expiração. Certificados expirados causam erros no navegador que impedem os usuários de acessar os serviços.

A revogação de certificados é o processo de invalidar um certificado antes da data de expiração programada. Os motivos para revogação incluem: a chave privada foi comprometida (o caso mais urgente — exige revogação imediata), o certificado foi emitido por engano (domínio incorreto, organização incorreta), as informações do Subject foram alteradas (a empresa mudou de nome, o funcionário saiu) ou a própria CA foi comprometida. A revogação é essencial porque navegadores e sistemas que não sabem que um certificado foi revogado continuarão confiando nele — dando a um invasor que possua a chave privada roubada capacidade ativa de MITM até que o certificado expire ou sua revogação seja conhecida.

Uma Certificate Revocation List (CRL) é uma lista assinada, publicada por uma CA, que contém os números de série de todos os certificados revogados por ela que ainda não expiraram. Os clientes baixam a CRL, armazenam-na em cache e verificam se o número de série de um certificado apresentado aparece na lista. As CRLs têm limitações importantes: podem ser muito grandes (CAs grandes têm milhões de certificados revogados), os clientes frequentemente as armazenam em cache por horas ou dias, introduzindo atraso, e baixar a CRL completa a cada conexão é ineficiente. As CRLs ainda são usadas, mas são cada vez mais complementadas ou substituídas por OCSP.

OCSP (Online Certificate Status Protocol) permite verificar a revogação de certificados em tempo real sem exigir que os clientes baixem CRLs inteiras. O cliente envia uma consulta ao respondente OCSP da CA com o número de série do certificado. O respondente responde com uma resposta assinada indicando que o certificado está válido, revogado (com a data e o motivo da revogação) ou desconhecido. O OCSP é mais rápido e oportuno que a CRL, mas cada conexão TLS exige uma ida e volta HTTP adicional ao respondente OCSP, o que aumenta a latência. As respostas OCSP são assinadas pela CA para impedir adulterações.

OCSP Stapling resolve o problema de latência da verificação OCSP em tempo real. Em vez de o cliente consultar o respondedor OCSP da CA durante cada handshake TLS, o servidor busca previamente sua própria resposta OCSP na CA e a “anexa” ao handshake TLS. O cliente recebe diretamente do servidor uma resposta OCSP recente e assinada pela CA — sem necessidade de uma viagem adicional. O servidor atualiza periodicamente sua resposta OCSP anexada (normalmente a cada hora). O OCSP Stapling melhora a velocidade da conexão e reduz a carga sobre os respondedores OCSP da CA, mantendo a verificação de revogação.

OCSP Must-Staple é uma extensão X.509 que informa aos navegadores que o servidor deve fornecer uma resposta OCSP anexada. Sem ela, os navegadores fazem uma “falha branda” quando a verificação OCSP falha — eles permitem a conexão mesmo assim, para evitar que indisponibilidades do respondedor OCSP bloqueiem todo o TLS. Um invasor pode explorar esse comportamento de falha branda bloqueando a solicitação OCSP do cliente, fazendo o certificado parecer válido mesmo após a revogação. OCSP Must-Staple impede isso ao exigir uma resposta anexada válida; sem ela, o navegador recusa a conexão. A adoção continua limitada devido à complexidade de implantação.

A revogação de certificados e a fixação de certificados abordam o mesmo problema — confiar em certificados fraudulentos —, mas por ângulos diferentes. Revogação (CRL/OCSP) é um mecanismo reativo: a CA invalida um certificado depois que um problema é descoberto. Fixação é um mecanismo proativo: o aplicativo recusa qualquer certificado que não seja um previamente aprovado. A fixação oferece garantias mais fortes do que a revogação porque funciona mesmo quando a CA não revoga o certificado prontamente, mas introduz rigidez na implantação. Para o exame Security+, conheça os dois mecanismos e entenda que a revogação é o mecanismo padrão da PKI, enquanto a fixação é uma medida opcional de defesa em profundidade.

Quando um certificado é revogado, a CA atribui um código do motivo da revogação que ajuda clientes e administradores a entenderem o motivo. Entre os códigos de motivo comuns definidos na RFC 5280 estão: keyCompromise (a chave privada foi comprometida), cACompromise (a CA emissora foi comprometida), affiliationChanged (a organização do titular foi alterada), superseded (um novo certificado foi emitido como substituto), cessationOfOperation (o domínio não está mais ativo) e privilegeWithdrawn (a autorização foi revogada). O código do motivo aparece tanto nas entradas da CRL quanto nas respostas OCSP, fornecendo contexto às equipes de resposta a incidentes que investigam eventos de revogação.

O protocolo ACME (Automatic gerenciamento de certificados), usado pela Let's Encrypt, automatiza todo o ciclo de vida dos certificados. Os clientes ACME (como o certbot) solicitam, renovam e implantam certificados automaticamente, sem intervenção humana. A CA usa desafios de validação de domínio para confirmar a propriedade do domínio: o desafio HTTP-01 exige colocar um arquivo específico em uma URL conhecida; o desafio DNS-01 exige criar um registro TXT de DNS. O ACME transformou o gerenciamento de certificados — os certificados de 90 dias da Let's Encrypt agora viabilizam uma grande parcela do tráfego HTTPS da internet, todos renovados automaticamente.

Test sua compreensão dos conceitos do CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu que o ciclo de vida do certificado vai da geração da CSR até a emissão, implantação e renovação ou revogação; a CRL fornece listas de revogação em lote, enquanto o OCSP fornece o status de cada certificado em tempo real; o OCSP Stapling elimina a latência do OCSP em tempo real; e o ACME (Let's Encrypt) automatiza todo o ciclo de renovação. A seguir, exploraremos os casos de uso da PKI.