O que é uma cadeia de certificados SSL? Como funciona

O que é uma cadeia de certificados SSL?

Uma cadeia de certificados SSL (também chamada de cadeia de confiança ou caminho de certificação) é a lista ordenada de certificados digitais que conecta o certificado SSL/TLS do seu site a uma autoridade certificadora (CA) raiz confiável. Cada certificado da cadeia é assinado digitalmente pelo de cima, criando um caminho de confiança verificável do seu servidor até uma CA raiz em que os navegadores já confiam.

Pense nisso como uma cadeia de recomendações. O certificado do seu servidor diz “Eu sou example.com”. A CA intermediária diz “Eu garanto o certificado de example.com”. A CA raiz diz “Eu garanto essa intermediária”. Seu navegador já confia na CA raiz, então, seguindo a cadeia de assinaturas, ele confia no seu servidor também.

Quando você visita um site HTTPS, seu navegador percorre essa cadeia em milissegundos. Se todos os elos estiverem corretos, a página carrega sem nenhum aviso. Se um elo estiver faltando, expirado ou não confiável, você recebe um aviso de segurança como NET::ERR_CERT_AUTHORITY_INVALID.

Os três tipos de certificado em uma cadeia

Toda cadeia tem três tipos de certificado, embora um servidor possa enviar mais de um intermediário:

Certificado raiz

O certificado raiz é a âncora de confiança no topo da cadeia. Ele é autoassinado, ou seja, a autoridade certificadora assinou o próprio certificado. Os certificados raiz vêm pré-instalados no seu navegador e sistema operacional; essa coleção se chama repositório de confiança (trust store).

A lista de raízes do próprio Chrome tem cerca de 100 (Chrome Root Store); Mozilla, Apple e Microsoft mantêm as suas. Organizações como DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign e Google Trust Services operam raízes. Como as chaves raiz valem tanto, as CAs as mantêm offline em módulos de segurança de hardware e as usam apenas para assinar intermediários.

Certificado intermediário

Os certificados intermediários ficam entre a raiz e o certificado do seu servidor. A CA raiz assina o certificado intermediário, e a CA intermediária assina então os certificados de entidade final (servidor). A maioria das CAs usa um ou dois intermediários.

Seu servidor web deve enviar os certificados intermediários junto com o certificado leaf durante o handshake TLS. O Chrome consegue baixar um intermediário faltante e o Firefox os traz pré-carregados, mas aplicativos, clientes de API e Androids antigos não têm nenhum dos dois, então para eles a cadeia quebra.

Certificado leaf (certificado do servidor)

O certificado leaf (também chamado de certificado de entidade final ou certificado do servidor) é o certificado instalado no seu servidor web. Ele contém o nome do seu domínio, sua chave pública, o período de validade e informações sobre o emissor (a CA intermediária que o assinou).

Este é o primeiro certificado que seu navegador recebe durante o handshake TLS. O navegador então percorre a cadeia para cima, verificando cada assinatura até alcançar uma raiz confiável.

Como a cadeia de confiança funciona

Quando seu navegador se conecta a um site via HTTPS, o handshake TLS aciona um processo de verificação de cadeia que acontece em milissegundos:

• O servidor envia seus certificados — o leaf e depois os intermediários.
• O navegador monta um caminho — do leaf até uma raiz da própria lista. Se um intermediário estiver faltando, o Chrome o baixa do endereço escrito no certificado (AIA), e o Firefox usa seu próprio conjunto pré-carregado; muitos outros clientes simplesmente falham.
• As assinaturas são verificadas — cada certificado deve ser assinado pela chave do de cima.
• A raiz é verificada — o caminho deve terminar em uma raiz da lista do navegador. Uma raiz desconhecida falha.
• A validade é verificada — todo certificado deve estar dentro das datas e não estar revogado, e o leaf deve cobrir o nome na barra de endereços.

Cadeias reais: o que 12 grandes sites enviam

Pedimos as cadeias de 12 dos maiores sites em 27 de outubro de 2026 (openssl s_client -showcerts, de dois locais). Nenhum enviou apenas um leaf, e vários enviaram certificados extras com assinatura cruzada para que dispositivos antigos ainda cheguem a uma raiz que conhecem. O que um servidor envia pode mudar conforme a sua versão do TLS, se o seu cliente suporta ECDSA e qual local da CDN responde: o facebook.com, por exemplo, enviou 3 certificados com TLS 1.2.

O que acontece após a verificação

Se todas as verificações passam, a conexão segue. Se uma única falha, mesmo em um intermediário, o navegador mostra um aviso como “Sua conexão não é particular” com um código como NET::ERR_CERT_AUTHORITY_INVALID. (Falhas antes de qualquer certificado ser examinado, no próprio handshake TLS, mostram outros códigos: ERR_SSL_PROTOCOL_ERROR ou ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

É por isso que a cadeia inteira importa, não só o certificado leaf. Um intermediário expirado quebra o HTTPS tanto quanto um certificado de servidor expirado, a menos que o cliente consiga montar outro caminho contornando-o.

Por que os certificados intermediários existem

As CAs raiz poderiam teoricamente assinar cada certificado de servidor diretamente, pulando os intermediários inteiramente. Mas há três razões críticas pelas quais elas não fazem isso:

• Isolamento de segurança — As chaves privadas da CA raiz são mantidas offline em HSMs dentro de cofres fisicamente seguros. Elas são usadas apenas para assinar intermediários, não milhões de certificados de servidor individuais. Isso reduz drasticamente o risco de a chave raiz ser comprometida.
• Contenção de danos — Se uma CA intermediária for comprometida, apenas os certificados dessa intermediária são afetados. A CA raiz pode revogar a intermediária comprometida e emitir uma nova — sem invalidar todos os certificados que já emitiu.
• Flexibilidade operacional — As CAs usam diferentes intermediários para diferentes propósitos: um para certificados DV, outro para EV, separados para diferentes regiões ou algoritmos de chave (RSA vs ECDSA).

Como verificar sua cadeia de certificados SSL

Existem três maneiras de inspecionar a cadeia de certificados de um site, desde ferramentas de linha de comando até verificações baseadas em navegador.

Método 1: OpenSSL (linha de comando)

O comando openssl é a maneira mais detalhada de inspecionar uma cadeia de certificados. Execute isso no seu terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Método 2: visualizador de certificados do navegador

Todos os principais navegadores mostram a cadeia que montaram (ela pode diferir da enviada pelo servidor, se eles mesmos buscaram um intermediário faltante):

• Chrome: clique no ícone à esquerda do endereço → A conexão é segura → O certificado é válido, depois abra a aba Detalhes para ver a hierarquia de certificados
• Edge: clique no cadeado → “Connection is secure” → o ícone de certificado no topo do painel
• Firefox: clique no cadeado → “Connection secure” → “More information” → “View Certificate”; cada certificado da cadeia ganha sua própria aba
• Safari (18.4 e posteriores): escolha Safari > Detalhes de Segurança da Conexão na barra de menus (Apple); no iPhone, toque no lado esquerdo do campo de endereço → “Privacy & Security” → “Connection Security Details”

Método 3: verificador SSL do DNS Robot

A forma mais rápida de verificar de fora da sua rede é o nosso Verificador SSL: ele mostra a cadeia que o servidor envia, se as listas de raízes de Mozilla, Chrome, Apple e Microsoft confiam nela, um aviso quando a cadeia está incompleta e as datas de cada certificado. Para sites atrás da Cloudflare ele lê o certificado dos logs CT públicos, então ali a cadeia enviada pelo servidor não é verificada.

Erros comuns na cadeia de certificados e como corrigi-los

Problemas na cadeia de certificados são uma das causas mais frequentes de erros HTTPS. Aqui estão os erros que você provavelmente encontrará e como resolver cada um.

Certificado intermediário ausente

Mensagem de erro: “unable to get local issuer certificate” (curl, Python, PHP), “unable to verify the first certificate” (Node.js) ou “incomplete certificate chain”

Causa: o servidor envia apenas o certificado leaf. O Chrome costuma consertar isso baixando o intermediário por conta própria (o verificador da Apple também), então o site pode parecer normal no navegador enquanto o curl no Linux, Python, Java, callbacks de pagamento e muitos aplicativos falham.

Correção: envie os intermediários junto com o leaf. Com a Let's Encrypt, aponte seu servidor para fullchain.pem, não para cert.pem; com outra CA, baixe o intermediário dela e coloque-o depois do seu certificado em um único arquivo:

cat your-domain.crt intermediate.crt > fullchain.crt

Certificado autoassinado na cadeia

Mensagem de erro: “self-signed certificate in certificate chain” (erro 19 do OpenSSL)

Causa: a cadeia termina em uma raiz em que o cliente não confia: uma CA privada ou corporativa, ou um proxy ou antivírus que reassina o tráfego com a própria raiz. Enviar uma raiz em que o cliente confia é inofensivo, apenas desnecessário.

Correção: use um certificado de uma CA pública em sites públicos, ou instale a raiz privada nos clientes que precisam dela. Deixar a raiz fora da cadeia do servidor é mais limpo, mas não corrige esse erro.

Ordem incorreta dos certificados

Mensagem de erro: a verificação da cadeia falha em alguns clientes, ou eles informam que o certificado não é confiável.

Causa: os certificados no arquivo da cadeia estão na ordem errada. O TLS 1.3 exige o certificado do próprio servidor primeiro e pede o restante em ordem, mas manda os clientes tolerarem outras ordens (RFC 8446 §4.4.2); clientes mais antigos ou mais rígidos podem não tolerar.

Correção: coloque o certificado leaf primeiro, depois cada intermediário, começando pelo que assinou o seu leaf.

Certificado expirado na cadeia

Mensagem de erro: “certificate has expired” — mas a data de expiração do seu certificado leaf parece certa.

Causa: um certificado mais acima na cadeia expirou. O caso mais conhecido: o DST Root CA X3 da IdenTrust, que havia assinado de forma cruzada a raiz da Let's Encrypt, expirou em 30 de setembro de 2021, e dispositivos que não confiavam na ISRG Root X1 (e clientes com OpenSSL 1.0.x) começaram a falhar em sites com Let's Encrypt.

Correção: baixe o certificado intermediário atual da sua CA e substitua o antigo. Depois use o nosso Verificador SSL para conferir a cadeia atualizada.

Melhores práticas para cadeia de certificados

• Sempre envie os intermediários — não conte com os navegadores para consertar a cadeia; aplicativos e clientes de API não vão consertar.
• A raiz é opcional — os clientes usam a própria cópia, então enviar uma raiz em que eles confiam só adiciona bytes; uma raiz com assinatura cruzada para dispositivos antigos é uma exceção deliberada.
• Mantenha a ordem — leaf primeiro, depois os intermediários, do que assinou o seu leaf para cima.
• Automatize a renovação — certificados emitidos desde março de 2026 duram no máximo 200 dias, caindo para 100 em março de 2027, e a Let's Encrypt passa para certificados de 64 dias em fevereiro de 2027.
• Verifique depois de cada renovação ou migração — uma CA pode trocar de intermediário entre renovações. Passe o site pelo Verificador SSL depois.
• Fique de olho em cada nome — www, o domínio sem prefixo e cada subdomínio podem ser servidos por certificados e cadeias diferentes. O Localizador de Subdomínios lista os nomes que seus certificados já cobriram, a partir dos logs públicos de certificados.