PKI e certificados: cadeias de confiança, emissão, renovação e revogação

O que é PKI e por que ela existe

PKI (Public Key Infrastructure) é o conjunto de componentes, processos e políticas que permitem usar criptografia de chave pública em escala para identificar entidades (pessoas, serviços, dispositivos) e estabelecer confiança entre elas. Na prática, PKI resolve um problema operacional: como um cliente pode ter confiança de que a chave pública que recebeu realmente pertence ao servidor correto (e não a um atacante), de forma repetível e auditável, sem depender de troca manual de chaves.

O mecanismo central da PKI é o certificado digital X.509: um documento assinado por uma Autoridade Certificadora (CA) que vincula uma chave pública a uma identidade e a um conjunto de restrições (por exemplo, para quais nomes de host o certificado é válido, para quais usos a chave pode ser empregada, por quanto tempo, e sob quais políticas). Em vez de “confiar na chave do servidor”, o cliente confia na assinatura da CA e nas regras de validação.

Componentes principais de uma PKI

Autoridade Certificadora (CA)

A CA emite certificados assinando-os com sua chave privada. Uma CA pode ser pública (confiada por sistemas operacionais e navegadores) ou privada (confiada apenas dentro de uma organização). Em ambientes corporativos, é comum ter uma CA raiz offline e uma ou mais CAs intermediárias online para emissão.

Autoridade de Registro (RA)

A RA é responsável por validar a identidade do solicitante antes da emissão. Em algumas arquiteturas, CA e RA são o mesmo sistema; em outras, a RA executa verificações (por exemplo, validação de domínio, aprovação de solicitação, checagem de inventário de ativos) e encaminha para a CA assinar.

Repositórios e distribuição

Certificados emitidos e informações de revogação precisam ser distribuídos. Isso pode ocorrer via diretórios (LDAP), endpoints HTTP para CRL, ou serviços OCSP. Em PKI privada, também é comum distribuir certificados e âncoras de confiança via MDM, GPO, ferramentas de configuração ou imagens de sistema.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Políticas e práticas (CP/CPS)

Uma PKI robusta não é só tecnologia: é processo. CP (Certificate Policy) e CPS (Certification Practice Statement) descrevem regras de emissão, validação, auditoria, proteção de chaves, perfis de certificados e procedimentos de revogação. Mesmo em PKI interna, documentar “quem pode pedir o quê” e “como aprovar” reduz risco e improviso.

Cadeias de confiança (chains of trust)

Um certificado raramente é assinado diretamente pela CA raiz. Em vez disso, usa-se uma cadeia: certificado do servidor (leaf) assinado por uma CA intermediária, que por sua vez é assinada por uma CA raiz. O cliente confia na raiz (trust anchor) e valida a cadeia até chegar nela.

Por que usar intermediárias

• Redução de impacto: a raiz pode ficar offline e protegida; se uma intermediária for comprometida, revoga-se a intermediária sem substituir a raiz em todos os clientes.

• Separação de funções: intermediárias diferentes podem emitir para propósitos distintos (TLS interno, dispositivos, usuários), com políticas e controles específicos.

• Escalabilidade: múltiplas intermediárias podem atender diferentes regiões/ambientes.

Como a validação de cadeia funciona (visão prática)

Quando um cliente recebe um certificado (por exemplo, em uma conexão TLS), ele tenta construir um caminho até uma âncora de confiança conhecida. Em termos práticos, a validação inclui:

• Construção do caminho: encontrar certificados intermediários necessários (enviados pelo servidor ou obtidos localmente).

• Verificação de assinaturas: cada certificado deve ser assinado pelo próximo na cadeia.

• Validade temporal: datas “not before” e “not after” devem estar ok.

• Restrições e extensões: Basic Constraints (CA=true/false), Key Usage, Extended Key Usage, Name Constraints (quando aplicável).

• Identidade: para TLS, o nome acessado deve bater com o SAN (Subject Alternative Name) do leaf.

• Status de revogação: checar CRL/OCSP conforme política do cliente.

Um erro comum em PKI privada é esquecer de distribuir a CA intermediária para os servidores (para que eles enviem a cadeia completa) ou esquecer de instalar a raiz nos clientes. Outro erro recorrente é emitir leaf com EKU inadequado (por exemplo, sem “serverAuth”), causando falha de validação.

Perfis e campos de certificados X.509 que você realmente usa

Subject e Subject Alternative Name (SAN)

Para TLS moderno, o SAN é o campo relevante para nomes DNS e IP. O Subject (CN) é legado e não deve ser a única fonte de identidade. Em prática: sempre inclua todos os nomes pelos quais o serviço será acessado (por exemplo, api.intra.exemplo, api, api.prod.svc.local, e eventualmente IPs, se necessário).

Key Usage e Extended Key Usage (EKU)

Key Usage define usos criptográficos (digitalSignature, keyEncipherment, keyCertSign etc.). EKU define o contexto (serverAuth, clientAuth, codeSigning, emailProtection). Em PKI interna, restrinja EKU para reduzir abuso: um certificado de servidor não deveria ser aceito como certificado de assinatura de código, por exemplo.

Basic Constraints

Define se o certificado é de CA (CA=true) e, opcionalmente, o path length. Intermediárias devem ter CA=true; leaf deve ter CA=false. Um erro de configuração aqui pode permitir que um certificado leaf seja tratado como CA em validações permissivas (ou quebrar validações corretas).

Subject Key Identifier (SKI) e Authority Key Identifier (AKI)

Ajudam a construir a cadeia corretamente, especialmente quando há múltiplas intermediárias. Em ambientes com várias CAs, SKI/AKI bem configurados evitam “cadeias erradas” e problemas intermitentes.

CRL Distribution Points e Authority Information Access (AIA)

CRL DP aponta onde obter listas de revogação. AIA pode apontar para OCSP e para o certificado da CA emissora. Em PKI privada, garanta que essas URLs sejam acessíveis a partir dos clientes reais (incluindo redes segmentadas e ambientes sem saída para internet).

Emissão de certificados: fluxo e decisões

Fluxo típico de emissão

O processo costuma seguir este caminho: (1) gerar um par de chaves; (2) criar uma CSR (Certificate Signing Request); (3) enviar para a RA/CA; (4) validar identidade e aprovar; (5) CA emite e assina; (6) instalar o certificado e a cadeia; (7) publicar/registrar para inventário e monitoramento.

Uma decisão importante é onde gerar a chave privada. Em geral, a chave privada deve ser gerada e permanecer no endpoint que vai usá-la (servidor, HSM, dispositivo), minimizando exposição. Para casos de alta criticidade, use HSM ou módulos de segurança equivalentes para geração e proteção da chave.

Passo a passo prático: gerar chave e CSR com OpenSSL (TLS servidor)

Exemplo para um serviço interno acessado por dois nomes DNS. Ajuste conforme sua política (tamanho de chave, algoritmo, etc.).

# 1) Gerar chave privada (exemplo RSA; em muitos ambientes ECDSA também é comum)openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server.key# 2) Criar arquivo de extensões com SANcat > san.cnf << 'EOF'[req]distinguished_name = dnreq_extensions = req_extprompt = no[dn]CN = api.intra.exemplo[req_ext]subjectAltName = @alt_nameskeyUsage = digitalSignature, keyEnciphermentextendedKeyUsage = serverAuth[alt_names]DNS.1 = api.intra.exemploDNS.2 = apiEOF# 3) Gerar CSRopenssl req -new -key server.key -out server.csr -config san.cnf

Pontos de atenção: (a) o SAN precisa refletir exatamente os nomes usados pelos clientes; (b) se você usa mTLS, o certificado do cliente deve ter EKU clientAuth; (c) evite reutilizar a mesma chave privada em múltiplos serviços.

Emissão automatizada (ACME) vs emissão manual

Emissão manual via CSR é útil para casos pontuais, mas escala mal e aumenta risco de expiração. Para TLS, automação é preferível. ACME (protocolo usado por várias soluções) permite emissão e renovação automatizadas com validação de domínio/controle do nome. Em PKI privada, é comum operar um servidor ACME interno para serviços internos, reduzindo trabalho operacional e evitando certificados expirados.

Critérios práticos para escolher automação:

• Ambiente com muitos serviços: automação quase obrigatória.

• Curta validade: quanto menor a validade, maior o benefício da automação.

• Ambientes segmentados: planeje o método de validação (DNS-01 costuma ser mais flexível do que HTTP-01 em redes fechadas).

Renovação: manter continuidade sem “apagões”

Renovação é a emissão de um novo certificado antes do vencimento do atual. Em muitos cenários, a renovação também é o momento de trocar chaves (rekey), embora isso dependa de política e criticidade. O objetivo é evitar interrupções e reduzir janela de exposição caso uma chave antiga tenha sido comprometida sem detecção.

Boas práticas operacionais de renovação

• Renovar cedo: defina um limiar (por exemplo, 30 dias antes do vencimento) e automatize alertas.

• Preferir rekey: gerar nova chave privada em renovações reduz risco acumulado.

• Implantação segura: instale o novo certificado em paralelo, valide, e só então faça o switch (quando o software permitir).

• Monitorar expiração: inventário central e varredura de endpoints ajudam a capturar certificados “esquecidos”.

Passo a passo prático: checar validade e cadeia antes de trocar

# Ver datas e SAN do certificadoopenssl x509 -in server.crt -noout -dates -subject -ext subjectAltName# Verificar se o certificado bate com a chave privada (comparando modulus no caso RSA)openssl x509 -in server.crt -noout -modulus | openssl sha256openssl rsa  -in server.key -noout -modulus | openssl sha256# Testar a cadeia (você precisa do bundle da intermediária/raiz conforme o caso)openssl verify -CAfile root.pem -untrusted intermediate.pem server.crt

Em TLS, um problema comum após renovação é o servidor passar a enviar uma cadeia incompleta. Garanta que o arquivo configurado no servidor inclua o leaf e as intermediárias necessárias (muitas stacks chamam isso de “fullchain”).

Revogação: quando um certificado ainda válido não deve mais ser aceito

Revogação é o mecanismo para invalidar um certificado antes do vencimento. Isso é necessário quando a chave privada pode ter sido comprometida, quando a identidade não é mais válida (por exemplo, serviço desativado), ou quando houve emissão incorreta (certificado com SAN errado, EKU errado, ou emitido para solicitante indevido).

CRL vs OCSP (diferenças práticas)

• CRL (Certificate Revocation List): lista assinada periodicamente pela CA contendo números de série revogados. Clientes baixam e consultam. Vantagens: simples, cacheável, funciona offline após obtida. Desvantagens: pode ficar grande; janela entre atualizações.

• OCSP (Online Certificate Status Protocol): consulta online por certificado. Vantagens: resposta mais “fresca”; não exige baixar lista grande. Desvantagens: depende de disponibilidade do responder; pode vazar metadados de navegação em cenários públicos; em ambientes internos, pode virar ponto único de falha se mal dimensionado.

Na prática, muitos clientes têm comportamento “soft-fail” para OCSP (se não conseguir consultar, aceitam mesmo assim), especialmente em ecossistemas web, para evitar indisponibilidade. Em PKI corporativa, você pode configurar políticas mais estritas em clientes controlados, mas isso exige garantir alta disponibilidade do OCSP/CRL e boa observabilidade.

Passo a passo prático: validar status de revogação (quando disponível)

# Consultar OCSP (você precisa do certificado da CA emissora e do URL do responder)openssl ocsp -issuer intermediate.crt -cert server.crt -url http://ocsp.intra.exemplo -CAfile root.pem# Baixar e inspecionar CRLopenssl crl -in ca.crl -noout -text

Se você opera a PKI, trate endpoints de CRL/OCSP como serviços críticos: monitore latência, taxa de erro, validade da CRL, e capacidade de atender picos (por exemplo, após reinício em massa de clientes).

Revogação de intermediárias e impacto

Revogar um leaf afeta apenas aquele serviço/identidade. Revogar uma CA intermediária afeta todos os certificados emitidos por ela, o que pode causar indisponibilidade ampla. Por isso, intermediárias devem ter controles mais fortes (proteção de chave, segregação de acesso, auditoria) e planos de contingência (intermediária substituta, reemissão em massa, distribuição rápida da nova cadeia).

Distribuição de confiança: como clientes passam a confiar na sua PKI

Em PKI pública, o trust store já vem no sistema operacional/navegador. Em PKI privada, você precisa distribuir a âncora de confiança (normalmente a raiz, às vezes também intermediárias) para todos os clientes que devem confiar. Isso inclui servidores, estações, dispositivos móveis, workloads em nuvem e appliances.

Boas práticas para trust stores internos

• Instalar apenas o necessário: confie na raiz corporativa, não em intermediárias diretamente, salvo necessidade específica.

• Controle de mudanças: trocar raiz é operação de alto impacto; planeje com antecedência, com período de sobreposição (cross-signing ou dupla confiança temporária).

• Inventário de dependências: identifique quais aplicações usam trust store próprio (Java, containers, runtimes embutidos) e precisam de atualização separada.

• Ambientes isolados: garanta que CRL/OCSP e AIA sejam resolvíveis internamente.

Erros comuns e como evitar

Certificado válido, mas nome não confere

Causa típica: SAN incompleto (faltou um alias, um nome curto, ou o nome do balanceador). Mitigação: inventariar todos os pontos de acesso e padronizar como nomes são usados; usar templates de CSR; validar com testes automatizados antes de promover.

Cadeia incompleta no servidor

Causa típica: servidor configurado apenas com o leaf. Mitigação: configurar “full chain” e testar com ferramentas de inspeção TLS. Em ambientes com proxies e balanceadores, valide em cada camada.

Uso indevido por falta de restrição

Causa típica: EKU amplo ou ausente, permitindo que um certificado seja aceito em contextos não pretendidos. Mitigação: templates de emissão com EKU estrito; revisão periódica de perfis; separação de CAs por finalidade.

Revogação ineficaz por indisponibilidade de CRL/OCSP

Causa típica: URLs inacessíveis, CRL expirada, OCSP fora do ar, ou clientes configurados para ignorar falhas. Mitigação: alta disponibilidade, cache, monitoramento, e testes de revogação como parte de exercícios operacionais (por exemplo, simular comprometimento e medir tempo até bloqueio efetivo).

Renovação manual esquecida

Causa típica: processos dependentes de pessoas e planilhas. Mitigação: automação (ACME ou pipelines internos), alertas e SLO de “zero certificados expirados em produção”.

Checklist operacional para PKI em ambientes reais

• Arquitetura: raiz offline; intermediárias online por finalidade; HSM quando necessário.

• Perfis: SAN obrigatório; EKU restrito; Basic Constraints correto; SKI/AKI consistentes.

• Emissão: validação de identidade clara; aprovação auditável; preferir automação para TLS.

• Renovação: renovar cedo; preferir rekey; testes de cadeia e de nome antes de trocar.

• Revogação: CRL/OCSP altamente disponíveis; monitorar validade e acessibilidade; processos de emergência.

• Distribuição de confiança: atualizar trust stores em todos os runtimes; mapear aplicações com stores próprios.

• Observabilidade: inventário de certificados, alertas de expiração, detecção de emissões fora de padrão.