Skip to main content
Resumo: A Sectigo migrou toda a emissão de certificados SSL para uma nova hierarquia de raízes em 2025. Se o seu servidor usa Windows Server 2012 R2 ou outro sistema desatualizado, pode ser necessário instalar manualmente o certificado cross-sign para que a cadeia SSL seja reconhecida corretamente.
Desde 2025, todos os certificados SSL emitidos pela SectigoDV, OV e EV — utilizam uma nova cadeia de confiança baseada na Root R46. O certificado em si está correto e válido — o que pode faltar é a raiz R46 no trust store de servidores mais antigos. Este artigo explica o que mudou, quem é afetado e como resolver.

1. O que mudou?

A Sectigo substituiu a cadeia de certificados intermediários e raízes utilizada na emissão de todos os tipos de certificados TLS (DV, OV e EV). Os certificados emitidos continuam sendo válidos e seguros — o que muda é o caminho de confiança (chain of trust) que o navegador ou sistema operacional percorre para validá-los. A nova hierarquia usa a mesma raiz R46 para todos os tipos. O que muda é o intermediário:
  1. DV (Domain Validation) — Intermediário: Sectigo Public Server Authentication CA DV R36
  2. OV (Organization Validation) — Intermediário: Sectigo Public Server Authentication CA OV R36
  3. EV (Extended Validation) — Intermediário: Sectigo Public Server Authentication CA EV R36

Cadeia anterior (antes de 2025)

Cadeia atual (a partir de 2025)

Comparativo

2. Cronograma da migração

3. Quem é afetado?

O seu certificado SSL está correto. O problema aparece apenas quando o servidor ou dispositivo do visitante não possui a raiz R46 instalada. Precisa instalar o cross-sign:
  1. Windows Server 2012 R2 — R46 ausente do trust store (caso mais comum)
  2. Windows Server 2012 ou anterior — R46 ausente (considerar migração de SO)
  3. Windows Server 2016 desatualizado — R46 pode estar ausente
  4. Linux sem atualizações recentes — executar update-ca-certificates
  5. Android < 7.1.1 — depende do cross-sign estar instalado no servidor
Não precisa fazer nada:
  1. Windows Server 2019+ (atualizado) — R46 já presente
  2. Windows Server 2016 (atualizado) — R46 recebido via Windows Update
  3. Linux com ca-certificates atualizado — R46 já presente
  4. Android 7.1.1+, macOS e iOS atualizados — R46 já presente
Caso mais comum: Clientes que hospedam o certificado Sectigo em um servidor Windows Server 2012 R2 com IIS.

4. Por que o sslchecker.com mostra erro?

Diferentes ferramentas de verificação SSL avaliam a cadeia de formas distintas. Isso pode causar confusão quando uma ferramenta mostra “OK” e outra mostra “cadeia incompleta”.
  1. SSL Labs (ssllabs.com) — Usa AIA para buscar certificados ausentes. Geralmente mostra “OK”
  2. decoder.link — Simula múltiplos clientes. Pode mostrar ambos os caminhos
  3. sslchecker.com — Validação estrita, sem AIA. Pode mostrar “cadeia incompleta”
  4. Chrome/Edge — Usa AIA + trust store do Windows. Funciona normalmente
  5. FirefoxNão usa AIA, depende do que o servidor envia. Pode falhar se a cadeia estiver incompleta
O que é AIA? O AIA (Authority Information Access) é uma extensão do certificado que contém URLs onde o cliente pode baixar automaticamente certificados intermediários ausentes. Navegadores como Chrome e Edge usam AIA, então “se viram” mesmo com cadeia incompleta. Já o Firefox e ferramentas como o sslchecker.com não usam AIA — eles avaliam apenas o que o servidor envia. Resumo: Se o sslchecker.com mostra erro mas o site funciona no Chrome, provavelmente o servidor não está enviando o certificado cross-sign na cadeia. A solução é instalá-lo.

5. Solução: Instalar o certificado cross-sign no Windows/IIS

O certificado cross-sign faz a ponte entre a nova raiz R46 e a antiga USERTrust RSA CA, que já está presente em praticamente todos os trust stores do mundo. Ao instalá-lo, o servidor passa a enviar uma cadeia que funciona tanto em sistemas novos quanto antigos:

Passo 1: Baixar os certificados

Baixe o cross-sign e o intermediário correspondente ao tipo do seu certificado:
  1. Root R46 cross-signed pela USERTrust: R46xUSERTrust.crt
  2. Intermediário (conforme o tipo do certificado):

Passo 2: Abrir o MMC (Console de Gerenciamento)

  1. No servidor Windows, pressione Win + R, digite mmc e pressione Enter
  2. Clique em Arquivo > Adicionar/Remover Snap-in
  3. Selecione Certificados e clique em Adicionar
  4. Escolha Conta de computador > Computador local > Concluir > OK

Passo 3: Importar o intermediário R36

  1. No painel esquerdo, expanda Certificados (Computador Local)
  2. Clique com o botão direito em Autoridades de Certificação Intermediárias > Certificados
  3. Selecione Todas as Tarefas > Importar
  4. Selecione o arquivo do intermediário R36 correspondente ao tipo do seu certificado (DV, OV ou EV)
  5. Confirme que o repositório é Autoridades de Certificação Intermediárias
  6. Conclua o assistente

Passo 4: Importar o cross-sign R46

  1. Repita o processo de importação na mesma pasta (Autoridades de Certificação Intermediárias)
  2. Selecione o arquivo do cross-sign R46 (R46xUSERTrust.crt)
  3. Conclua o assistente

Passo 5: Verificar a raiz USERTrust

  1. Navegue até Autoridades de Certificação Raiz Confiáveis > Certificados
  2. Confirme que USERTrust RSA Certification Authority está presente na lista
  3. Se não estiver, baixe-o em crt.sh e importe nesta pasta

Passo 6: Reiniciar o IIS

Abra o Prompt de Comando como Administrador e execute:

Passo 7: Verificar

  1. Acesse sslchecker.com e digite o domínio
  2. A cadeia deve aparecer completa, sem alertas de “chain issues”
  3. Teste também em decoder.link e SSL Labs para confirmar
Dica: Após instalar os certificados no MMC, pode ser necessário recriar o binding SSL no IIS (remover e adicionar novamente o certificado no site) para que o IIS reconstrua o caminho da cadeia.

6. Onde baixar os certificados

Cross-sign e raízes (comuns a todos os tipos):
  1. Cross-sign R46 x USERTrust (faz a ponte com a raiz antiga) — Download
  2. Root R46 self-signed (raiz da nova hierarquia) — Download
  3. USERTrust RSA CA (raiz antiga, compatibilidade universal) — crt.sh #1199354
Intermediários (escolha conforme o tipo do seu certificado):
  1. DV R36 (Domain Validation) — Download
  2. OV R36 (Organization Validation) — Download
  3. EV R36 (Extended Validation) — Download
Referência para verificar os certificados:
  1. Root R46 (self-signed) — CN: Sectigo Public Server Authentication Root R46 — Validade: 2021–2046
  2. Root R46 (cross-signed) — CN: Sectigo Public Server Authentication Root R46 (emitido pela USERTrust) — Validade: 2021–2038
  3. DV R36 — CN: Sectigo Public Server Authentication CA DV R36 — Validade: 2021–2036
  4. OV R36 — CN: Sectigo Public Server Authentication CA OV R36 — Validade: 2021–2036
  5. EV R36 — CN: Sectigo Public Server Authentication CA EV R36 — Validade: 2021–2036
  6. USERTrust RSA CA — CN: USERTrust RSA Certification Authority — Validade: 2010–2038
  7. AAA Certificate Services — CN: AAA Certificate Services — Validade: 2004–2028

7. Perguntas frequentes

Meu certificado está inválido?

Não. O certificado emitido pela Sectigo está correto e válido. O que pode estar faltando é o certificado cross-sign (que faz a ponte entre a nova raiz e a antiga) instalado no seu servidor. O certificado em si não precisa ser substituído.

Preciso reemitir o certificado?

Não. Basta instalar o certificado cross-sign R46 no servidor, conforme o passo a passo acima. O certificado do seu domínio permanece o mesmo.

Por que funciona no Chrome mas não no Firefox?

O Chrome (e o Edge) utilizam AIA fetching: eles automaticamente buscam certificados intermediários ausentes pela internet. O Firefox não faz isso — ele depende exclusivamente do que o servidor envia. Se o servidor não envia o cross-sign, o Firefox pode mostrar erro. Instalar o cross-sign no servidor resolve para todos os navegadores.

Windows Server 2012 R2 ainda é suportado?

O Windows Server 2012 R2 atingiu o fim do suporte (EOL) em outubro de 2023. As Extended Security Updates (ESU) continuam até outubro de 2026. Recomendamos planejar a migração para uma versão mais recente do Windows Server.

Fiz a instalação mas o sslchecker ainda mostra erro

Algumas possibilidades:
  1. Cache do sslchecker: Aguarde alguns minutos e teste novamente
  2. IIS não reconstruiu a cadeia: Remova e adicione novamente o binding SSL do site no IIS Manager
  3. Certificado importado no local errado: Confirme que o cross-sign está em “Autoridades de Certificação Intermediárias”, não em “Raiz Confiável”
  4. Windows Update adicionou o R46 self-signed na raiz: Neste caso o IIS pode preferir o caminho curto (sem cross-sign). Veja a seção de referências para instruções avançadas

8. Verificação por linha de comando

Para verificar qual cadeia o servidor está enviando:
O resultado esperado após a correção:
Para verificar a cadeia completa:

9. Referências


Dúvidas sobre essa atualização? Fale com nosso suporte.