A Autoridade de Certificação Sectigo (Comodo) alertou os usuários com antecedência sobre a expiração do certificado raiz AddTrust , usado para assinatura cruzada, para garantir a compatibilidade com dispositivos legados que não possuem um novo certificado raiz USERTrust em sua loja.O AddTrust expirou em 20 de maio de 2020 às 10:48:38 UTC. Infelizmente, surgiram problemas não apenas em navegadores desatualizados, mas também em clientes que não são navegadores, baseados no OpenSSL 1.0.x, LibreSSL e GnuTLS . Por exemplo, nos decodificadores Roku (veja a resposta no suporte técnico de 30/05/2020), Heroku , no Fortinet, aplicativos Chargify, na plataforma .NET Core 2.0 no Linux e muitos outros.Supunha-se que o problema afetaria apenas sistemas legados (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 etc.), pois os navegadores modernos podem usar o segundo certificado raiz USERTRust, conforme mostrado no diagrama.
Cadeia de certificadosMas, em 30 de maio de 2020, de fato, as falhas começaram em centenas de serviços da Web que usavam as bibliotecas gratuitas OpenSSL 1.0.xe GnuTLS. Uma conexão segura deixou de ser estabelecida com um erro de obsolescência do certificado.O ticket correspondente no rastreador de erros do OpenSSL (nome de usuário e senha: convidado) foi fechado em 25 de fevereiro de 2020 apenas para a versão OpenSSL 1.1.0.Por que ocorre um erro
Quando um cliente se conecta, o servidor TLS envia seu certificado. O cliente deve criar uma cadeia de certificados do certificado do servidor para o certificado raiz em que o cliente confia. Para ajudar o cliente a construir essa cadeia, o servidor envia um ou mais certificados intermediários adicionais, juntamente com os seus.
Por exemplo, um site envia os dois certificados a seguir:1
Assunto = * .habr.com
Editor = CA do servidor seguro de validação de domínio ECC do Sectigo ECC
Início da ação = sábado, 30 de maio de 2020 3:00:00
Data de validade = sexta-feira, 3 de dezembro de 2021 2:59:59
2)
Subject = CA do servidor seguro de validação de domínio do Sectigo ECC
Editor = Autoridade de certificação USERTrust ECC
Início da ação = sexta-feira, 2 de novembro de 2018 3:00:00
Fim da ação = quarta-feira, 1 de janeiro de 2031 2:59:59
O primeiro certificado pertence ao servidor e é emitido pela autoridade de certificação Sectigo. O segundo é emitido pela autoridade de certificação USERTrust ECC e é o certificado raiz. Esses dois certificados formam uma cadeia completa para uma raiz confiável.No entanto, a autoridade de certificação USERTrust é uma raiz relativamente nova. Foi criado em 2010 e levou muitos anos para que todos os clientes confiassem. No ano passado, houve relatos de que clientes individuais não confiam nessa raiz. Portanto, alguns servidores enviam um certificado intermediário adicional da USERTrust ECC Certification Authority emitido pelo AddTrust External CA Root ao cliente. Este certificado foi gerado em 2000 e foi o seu certificado que expirou em 30 de maio de 2020.Para validadores de certificados competentes, incluindo navegadores modernos, isso não causou problemas, porque eles mesmos podem criar uma cadeia de confiança antes do USERTrust, mas houve um problema com os clientes que usam o OpenSSL 1.0.x ou o GnuTLS. Mesmo que esses clientes confiem na autoridade de certificação raiz USERTrust e desejem criar uma cadeia para ela, eles ainda acabam com uma cadeia para a raiz da CA externa AddTrust, que causa falha na verificação do certificado.A Sectigo forneceu um certificado intermediário alternativo com assinatura cruzada AAA Certificate Services , que será válido até 2028.Verificando seus serviços
O manipulador de servidores e os operadores de aplicativos clientes são incentivados a verificar sua cadeia de certificados em busca de um certificado raiz AddTrust desatualizado.Essencialmente, você só precisa remover a Raiz da CA externa do AddTrust da cadeia de confiança.Para operadores de servidor, existe um serviço What's My Chain Cert? , que executa essa verificação e ajuda a gerar uma nova cadeia confiável com todos os certificados intermediários necessários. Não é necessário incluir um certificado raiz nessa cadeia, pois todos os clientes já o possuem na loja. Além disso, incluí-lo na cadeia é simplesmente ineficiente devido ao aumento no tamanho do handshake SSL.Os operadores de aplicativos clientes são aconselhados a atualizar para a biblioteca TLS mais recente. Se isso não for possível, você deve remover o certificado Raiz da CA externa do AddTrust do seu armazenamento. Se não estiver no repositório, a cadeia de confiança correta será criada para a nova autoridade de certificação USERTrust RSA Certification raiz, para que a verificação TLS passe corretamente.Para remover a raiz da CA externa do AddTrust, faça o seguinte :- Editar
/etc/ca-certificates.confe comentarmozilla/AddTrust_External_Root.crt
- Corre
update-ca-certificates
Para corrigir o problema, o Fedora e o RHEL sugerem adicionar o certificado AddTrust à lista negra: trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert" \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract
Mas esse método não funciona para o GnuTLS.Veja também:
“ O problema com os certificados Sectigo após 30 de maio de 2020 e o método de solução ” no blog corporativo da Habr
Soluções de PKI para sua empresa. Entre em contato conosco +7 (499) 678 2210, sales-ru@globalsign.com.