Introdução
HTTPS (via SSL /TLS) usa criptografia de chave pública para impedir que as comunicações do navegador sejam lidas ou modificadas em trânsito pela Internet. Os servidores fornecem aos navegadores visitantes uma chave pública usada para estabelecer uma conexão criptografada para todas as trocas de dados subsequentes.
No entanto, apenas receber um trabalhar a chave pública sozinha não garante que ela (e, por extensão, o servidor) seja de fato propriedade do controle remoto correto sujeito (ou seja, pessoa, empresa ou organização). Man-in-the-middle os invasores podem manipular redes para servir suas próprias chaves, comprometendo assim qualquer comunicação.
Os navegadores evitam isso autenticando Servidores HTTPS usando certificados, que são documentos digitais que vincular uma chave pública para um sujeito individual. A vinculação é afirmada por meio de uma chave confiávelautoridade de certificação (CA) como SSL.com verifique a identidade dos possíveis proprietários de certificados, por meio de verificações automatizadas e manuais em bancos de dados qualificados.
Essa relação de confiança significa que a segurança do usuário da web não é absoluta; em vez disso, exige que os usuários confiem nos navegadores e nas CAs para proteger sua segurança. Portanto, é do interesse de todos os usuários ter um conhecimento básico de como funciona a validação de certificados.
Observe que o processo de validação do certificado (descrito em detalhes no documento padrão RFC 5280) é bastante complicado. Neste artigo, tentaremos guiá-lo ao longo de um caminho (um navegador que valida o SSL /TLS certificado) e navegue pelos detalhes complexos e irrelevantes para a maioria dos usuários.
Observação: Em agosto de 2024, RFC 9618, um documento da Internet Engineering Task Force (IETF), atualizou o algoritmo para validação de restrições de política em certificados digitais X.509 do RFC 5280.
Certificados e o formato X.509
Certificados são arquivos digitais em todos os aspectos, o que significa que precisam seguir um formato de arquivo para armazenar informações (por exemplo, assinaturas, chaves, emissores, etc.). Embora sejam privados, PKI configurações podem implementar qualquer formato para seus certificados, publicamente confiáveis PKIs (ou seja, aqueles confiáveis pelos navegadores) devem estar em conformidade com o RFC 5280, que exige o uso do X.509 v3 formato.
O X.509 v3 permite que os certificados incluam dados adicionais, como restrições de uso ou informações de política, como extensões, com cada extensão sendo crítico or não crítico. Se um cliente encontrar uma extensão não crítica não reconhecida, ele poderá ignorá-la. Se uma extensão for crítica e não reconhecida ou não puder ser processada, o certificado deverá ser rejeitado.
Caminhos de certificação e processamento de caminhos
As ACs usam uma chave privada para assinar criptograficamente todos os certificados emitidos. Essas assinaturas podem criptograficamente provar que um certificado foi emitido por uma CA específica e que não foi modificado após ser assinado.
As CAs estabelecem a propriedade de sua chave de assinatura mantendo um certificado emitido automaticamente (chamado de raiz) para a chave pública correspondente. As ACs devem observar procedimentos rigorosamente controlados e auditados para criar, gerenciar e utilizar uma raiz e, para minimizar a exposição, normalmente usarão uma raiz para emitir intermediário certificados. Esses intermediários podem então ser usados para emitir os certificados de seus clientes. Um certificado de CA raiz é autoassinado e a chave privada é protegida por procedimentos rigorosos. A emissão normalmente ocorre por meio de intermediários, não diretamente das autoridades raiz.
Os navegadores são fornecidos com uma lista interna de raízes confiáveis. (Estas são raízes de CAs que passaram pelos rigorosos critérios do navegador para inclusão.) Para verificar um certificado, um navegador obterá uma sequência de certificados, cada um assinando o próximo certificado na sequência, conectando a raiz da CA de assinatura à do servidor certificado.
Essa sequência de certificados é chamada de caminho de certificação. A raiz do caminho é chamada de âncora de confiança e o certificado do servidor é chamado de folha or entidade final certificado.
Construção de Caminho
Frequentemente, navegadores web e clientes de software em geral podem construir múltiplas âncoras de confiança candidatas (por exemplo, devido a sinais cruzados) e frequentemente buscar intermediários ausentes via AIA para completar uma cadeia. Mesmo que um caminho possa conter certificados que se "encadeiam" corretamente a uma âncora conhecida, o próprio caminho pode ser rejeitado devido a restrições de comprimento do caminho, nome de domínio, uso de certificado ou política.
Construir e avaliar todos os caminhos possíveis é um processo caro, executado para cada novo certificado que um navegador encontra. Os navegadores implementaram várias otimizações para minimizar o número de caminhos de candidatos rejeitados, mas investigar esses detalhes está muito além do escopo deste artigo.
Validação de caminho
Depois que um caminho de certificação do candidato é construído, os navegadores o validam usando as informações contidas nos certificados. Um caminho é válido se os navegadores puderem provar criptograficamente que, partindo de um certificado assinado diretamente por uma âncora de confiança, a chave privada correspondente de cada certificado foi usada para emitir a próxima no caminho, até o certificado folha.
Os requisitos básicos exigem que os nomes do Assunto e do Emissor em todos os caminhos possíveis be idêntico byte por byte, o que simplifica a construção de caminhos confiáveis.
Algoritmo de validação de caminho de certificação
Conforme observado anteriormente, em agosto de 2024, RFC 9618, um documento da Internet Engineering Task Force (IETF), atualizou o algoritmo para validar restrições de política em certificados digitais X.509 do RFC 5280. Basicamente, os navegadores iteram por todos os certificados no caminho, começando pela âncora de confiança (ou seja, o certificado raiz), validando as informações básicas e extensões críticas de cada certificado.
Se o procedimento for concluído com o último certificado no caminho sem erros, o caminho será aceito como válido. Se forem produzidos erros, o caminho é marcado como inválido.
Processamento básico de certificados
Independentemente de qualquer extensão, os navegadores sempre devem verificar as informações básicas do certificado, como a assinatura ou o emissor. As seções a seguir mostram a sequência de verificações executadas pelos navegadores.
1. O navegador verifica a integridade do certificado
O assinatura no certificado pode ser verificado usando criptografia de chave pública normal. Se a assinatura for inválida, o certificado será considerado modificado após sua emissão e, portanto, será rejeitado.
2. O navegador verifica a validade do certificado
Um certificado período de validade é o intervalo de tempo durante o qual a CA de assinatura garante que manterá informações sobre seu status. Os navegadores rejeitam todos os certificados com um período de validade que termina antes ou depois da data e hora da verificação de validação.
3. O navegador verifica o status de revogação do certificado
Quando um certificado é emitido, espera-se que ele seja usado por todo o seu período de validade. Obviamente, várias circunstâncias podem tornar um certificado inválido antes de expirar naturalmente.
Tais circunstâncias podem incluir um assunto mudando seu nome ou uma suspeita de comprometimento de sua chave privada. Em casos como esse, uma CA precisa revogar o certificado correspondente e os usuários também confiam em uma CA para notificar os navegadores sobre o status de revogação de seus certificados.
Listas de revogação de certificado (CRL)
As Listas de Revogação de Certificados (CRLs) se tornaram o padrão do setor para verificação de revogação de certificados a partir de 2024. As CAs emitem periodicamente listas assinadas e com registro de data e hora de certificados revogados que os navegadores podem baixar e armazenar em cache localmente.
Embora as CRLs fossem anteriormente consideradas menos eficientes do que os métodos de verificação em tempo real, o setor reconheceu vantagens significativas que as tornam a abordagem preferida:
- Privacidade aprimorada: As CRLs protegem a privacidade do usuário eliminando a necessidade de consultar servidores externos sobre certificados específicos, o que poderia revelar padrões de navegação
- Eficiência Operacional: As ACs podem gerenciar a revogação de forma mais eficiente sem manter serviços de resposta em tempo real de alta disponibilidade
- Custos reduzidos de infraestrutura: A eliminação da necessidade de equipes de resposta OCSP 24 horas por dia, 7 dias por semana, reduz significativamente a sobrecarga operacional
- Melhor cache: Os navegadores modernos podem armazenar em cache e atualizar CRLs de forma eficiente, minimizando as preocupações com latência que antes favoreciam os métodos em tempo real
A partir de março 2024, o CA/Browser Forum exige que todas as CAs publicamente confiáveis forneçam CRLs, ao mesmo tempo que tornam outros métodos de revogação opcionais. Algumas das principais autoridades de certificação descontinuaram serviços alternativos de revogação em favor de abordagens somente de CRL.
Protocolo de status de certificado on-line (OCSP)
O Protocolo de Status de Certificado Online (OCSP), descrito em RFC 6960, foi projetado para fornecer verificação de revogação de certificados em tempo real, permitindo que navegadores consultem servidores OCSP (respondentes) sobre certificados específicos. Embora o OCSP tenha sido amplamente adotado na década de 2010 como uma melhoria em relação aos downloads periódicos de CRLs, o setor se distanciou amplamente dessa abordagem.
- O OCSP agora é opcional para CAs de confiança pública (em vigor a partir de março de 2024). A importância do OCSP é declinante; por exemplo, Let’s Encrypt removeu URLs OCSP em maio de 2025 e desligou os respondentes em Agosto de 2025.
- Alguns navegadores desabilitaram a verificação OCSP ou a implementaram de maneiras que fornecem benefícios mínimos de segurança
Grampeamento OCSP: Uma variante chamada Grampeamento OCSP continua útil em alguns cenários, onde os servidores incluem respostas OCSP diretamente no TLS handshake, evitando consultas separadas de clientes aos respondedores OCSP. No entanto, isso requer configuração específica do servidor. O grampeamento é suportado pela maioria dos servidores/CDNs, mas sua utilidade está diminuindo à medida que grandes CAs retiram o OCSP.
Como isso realmente funciona hoje em navegadores: Desde 15 de março de 2024, o Fórum CA/B exige que CAs publicamente confiáveis publiquem CRLs, enquanto o OCSP é opcional. Navegadores modernos geralmente não consultam o OCSP nem baixam CRLs por site. Em vez disso, eles usam mecanismos agregados criados a partir de CRLs publicadas por CAs: o CRLSets do Chrome e o CRLite do Firefox fornecem dados de revogação rápidos e que preservam a privacidade aos clientes. Como resultado, o papel do OCSP na Web pública está diminuindo; por exemplo, o Let's Encrypt removeu URLs do OCSP em maio de 2025 e desativou os respondedores do OCSP em agosto de 2025.
4. O navegador verifica o emissor
Os certificados são normalmente associados a duas entidades:
- O emissor, que é a entidade proprietária da chave de assinatura e
- O sujeito, que se refere ao proprietário da chave pública que o certificado autentica.
Os clientes verificam se cada certificado no caminho é assinado pela chave pública do certificado anterior e se os nomes do Emissor/Assunto correspondem exatamente ao longo do caminho. Para maior segurança, a maioria PKI As implementações também verificam se a chave do emissor é a mesma que assinou o certificado atual. (Observe que isso não se aplica à âncora de confiança, já que as raízes são autoemitidas – ou seja, têm o mesmo emissor e sujeito.)
Processamento de restrições
O formato X.509 v3 permite que uma CA defina restrições ou restrições sobre como cada certificado é validado e usado como extensões críticas. Todo certificado no caminho pode impor restrições adicionais às quais todos os certificados subsequentes devem obedecer.
As restrições de certificado raramente afetam o usuário médio da Internet, embora sejam bastante comuns em soluções SSL corporativas. As restrições funcionais podem servir a vários propósitos operacionais, mas seu uso mais significativo é mitigar preocupações de segurança conhecidas.
5. O navegador verifica as restrições de nome
Uma CA intermediária de propriedade privada (mas publicamente confiável) com o apropriado restrições de nome pode fornecer a uma organização um controle preciso sobre o gerenciamento e a emissão de certificados. Os certificados podem ser limitados a um domínio ou árvore de domínio específico (ou seja, incluindo subdomínios) para o nome de domínio de uma empresa ou organização. Restrições de nome são frequentemente usadas para certificados de CA intermediários adquiridos de uma CA publicamente confiável para impedir que a CA intermediária emita certificados perfeitamente válidos para domínios de terceiros (por exemplo, google.com).
6. O navegador verifica as restrições de política
Uma política de certificado é um documento legal publicado por uma CA, detalhando oficialmente os procedimentos a serem seguidos para emitir e gerenciar seus certificados. As autoridades de certificação podem emitir um certificado sob uma ou mais políticas, e os links para eles são incluídos em cada certificado emitido, para que as partes confiáveis possam avaliar essas políticas antes de decidir confiar nesse certificado.
Por razões legais e operacionais, os certificados podem impor restrições às políticas às quais estão sujeitos. Se um certificado contiver restrições críticas de política, os navegadores deverão validá-los antes de continuar. (No entanto, restrições críticas de políticas raramente são encontradas no mundo real e, portanto, serão desconsideradas no restante deste artigo.)
7. O navegador verifica restrições básicas (também conhecidas como comprimento do caminho)
O formato X.509 v3 permite que os emissores definam o comprimento máximo do caminho que um certificado pode suportar. Isso fornece controle sobre até que ponto cada certificado pode ser colocado em um caminho de certificação. Isso é realmente importante - os navegadores costumavam desconsiderar o comprimento do caminho de certificação até que um pesquisador demonstrou, em um 2009 apresentação de negócios, como ele usou o certificado de folha do seu site para falsificar um certificado válido para um grande site de comércio eletrônico.
8. O navegador verifica o uso da chave
A extensão “uso da chave” declara o propósito da chave contida no certificado. Exemplos de tais finalidades incluem criptografia, assinaturas, assinatura de certificado e assim por diante. Os navegadores rejeitam certificados que violam suas restrições de uso de chave, como encontrar um certificado de servidor com uma chave destinada apenas para assinatura CRL.
9. O navegador continua processando todas as extensões críticas restantes
Depois de processar as extensões mencionadas acima, os navegadores continuam a validar todas as extensões restantes que o certificado atual designa como críticas, antes de passar para o próximo. Se um navegador alcançar o certificado folha de um caminho sem erros, o caminho será aceito como válido. Se algum erro for produzido, o caminho será marcado como inválido e uma conexão segura não será estabelecida.
Gestão moderna de certificados: vida útil mais curta e automação
O SSL /TLS O setor passou por diversas mudanças nos últimos anos, alterando fundamentalmente a forma como os certificados são emitidos e gerenciados. Compreender essas mudanças é crucial para PKI gerentes, profissionais de TI e/ou qualquer pessoa que trabalhe com certificados digitais.
Períodos de validade de certificados reduzidos
Em abril de 2025, o CA/Browser Forum aprovou uma decisão histórica (Cédula SC-081v3) para reduzir drasticamente os períodos de validade dos certificados em fases:
- Atual (até março de 2026): Máximo 398 dias (aproximadamente 13 meses)
- 15 de março de 2026: Máximo 200 dias
- 15 de março de 2027: Máximo 100 dias
- 15 de março de 2029: Máximo 47 dias
Alterações na Validação de Controle de Domínio (DCV)
Além da vida útil dos certificados, o período de reutilização de informações de validação de domínio também está diminuindo:
- Março de 2026: : 200 dias de reutilização máxima
- Março de 2027: : 100 dias de reutilização máxima
- Março de 2029: : 10 dias de reutilização máxima
Isso significa que as organizações precisarão validar a propriedade do domínio com muito mais frequência, tornando a automação essencial para o gerenciamento prático de certificados.
Por que essas mudanças são importantes
Benefícios de segurança:
- Vidas de certificado mais curtas reduzem a janela de exposição quando as chaves são comprometidas
- Validação mais frequente garante que a propriedade do domínio permaneça atualizada
- Implementação mais rápida de melhorias de segurança na web
Impacto Operacional:
- A gestão manual de certificados torna-se praticamente impossível
- As organizações devem implementar o gerenciamento automatizado do ciclo de vida do certificado
- Procedimentos de validação de domínio mais frequentes são necessários
Requisitos de automação
Essas mudanças tornam a automação de certificados não apenas benéfica, mas essencial. As organizações devem considerar seriamente:
- Executar ACME (Ambiente de Gerenciamento Automático de Certificados) ou protocolos semelhantes
- Implementar soluções de gerenciamento do ciclo de vida do certificado
- Preparar a infraestrutura para renovações e validações frequentes
- Prepare-se para a transição para certificados com vida útil mais curta
Integração de Transparência de Certificados
Os navegadores modernos exigem ou validam cada vez mais logs de Transparência de Certificados (CT), que fornecem registros públicos e auditáveis de todos os certificados emitidos. Isso ajuda a detectar:
- Certificados emitidos incorretamente
- Emissão de certificado não autorizada
- Problemas de conformidade com a CA
Conclusão
O cenário digital continua sendo um sistema complexo de componentes interconectados, e a segurança do navegador continua sendo uma área ativa de desenvolvimento que inclui:
- Certificados com vida útil mais curta: O setor está caminhando para períodos de validade de certificados de 47 dias até 2029, tornando a automação essencial para o gerenciamento prático de certificados
- Alterações no método de revogação: A mudança do OCSP para as CRLs reflete a priorização da indústria em relação à privacidade do usuário e à eficiência operacional
- Supervisão mais rigorosa da CA: Os navegadores tornaram-se mais agressivos na aplicação da conformidade e na remoção da confiança de autoridades de certificação de baixo desempenho
Essas mudanças representam uma mudança fundamental em direção a um gerenciamento de certificados mais automatizado, com foco na privacidade e na segurança. As organizações devem começar a se preparar agora para ciclos de vida de certificados mais curtos e processos de renovação automatizados.
A confiança continua a desempenhar um papel fundamental na segurança dos usuários online. Recomendamos que você se mantenha informado sobre a evolução desses padrões e revise as políticas e o histórico de conformidade da sua autoridade certificadora. Como essas mudanças demonstram, o ecossistema de certificados se adapta ativamente para aprimorar a segurança e a proteção da privacidade.
Para obter as informações mais atualizadas sobre as melhores práticas de gerenciamento de certificados e a abordagem da SSL.com para essas mudanças no setor, visite nosso página de comparação de certificados.
Obrigado por escolher SSL.com, onde acreditamos que um mais segura Internet é uma better Internet.
