L'Autorité de certification Sectigo (Comodo) a averti les utilisateurs à l'avance de l'expiration du certificat racine AddTrust , qui était utilisé pour la signature croisée, afin d'assurer la compatibilité avec les appareils hérités qui n'ont pas de nouveau certificat racine USERTrust dans leur magasin.AddTrust a expiré le 20 mai 2020 à 10:48:38 UTC. Malheureusement, des problèmes sont survenus non seulement dans les navigateurs obsolètes, mais aussi dans les clients sans navigateur basés sur OpenSSL 1.0.x, LibreSSL et GnuTLS . Par exemple, dans les décodeurs Roku (voir la réponse dans le support technique du 30/05/2020), Heroku , dans Fortinet, les applications Chargify, sur la plate-forme .NET Core 2.0 sous Linux et bien d'autres.Il a été supposé que le problème n'affecterait que les systèmes hérités (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), car les navigateurs modernes peuvent utiliser le deuxième certificat racine USERTRust, comme indiqué dans le diagramme.
Chaîne de certificatsMais le 30 mai 2020, en fait, des plantages ont commencé dans des centaines de services Web qui utilisaient les bibliothèques gratuites OpenSSL 1.0.x et GnuTLS. Une connexion sécurisée a cessé d'être établie avec une erreur d'obsolescence de certificat.Le ticket correspondant dans le traqueur de bogues d'OpenSSL (nom d'utilisateur et mot de passe: invité) a été fermé le 25 février 2020 uniquement pour la version OpenSSL 1.1.0.Pourquoi une erreur se produit
Lorsqu'un client se connecte, le serveur TLS lui envoie son certificat. Le client doit créer une chaîne de certificats du certificat de serveur au certificat racine auquel le client fait confiance. Pour aider le client à créer cette chaîne, le serveur envoie un ou plusieurs certificats intermédiaires supplémentaires avec le sien.
Par exemple, un site Web envoie les deux certificats suivants:1.
Subject = * .habr.com
Publisher = Autorité de certification Sectigo ECC Domain Validation Secure Server
Début de l'action = samedi 30 mai 2020 3:00:00
Date d'expiration = vendredi 3 décembre 2021 2:59:59
2.
Subject = Autorité de certification Sectigo ECC Domain Validation Secure Server
Éditeur = USERTrust ECC Certification Authority
Début de l'action = vendredi 2 novembre 2018 3:00:00
Fin de l'action = mercredi 1 janvier 2031 2:59:59
Le premier certificat appartient au serveur et est émis par l'autorité de certification Sectigo. Le second est délivré par l'autorité de certification USERTrust ECC et est le certificat racine. Ces deux certificats forment une chaîne complète vers une racine approuvée.Cependant, l'autorité de certification USERTrust est une racine relativement nouvelle. Il a été créé en 2010 et il a fallu de nombreuses années à tous les clients pour lui faire confiance. L'année dernière, il a été signalé que les clients individuels ne faisaient pas confiance à cette racine. Par conséquent, certains serveurs envoient au client un certificat intermédiaire USERTrust ECC Certification Authority supplémentaire émis par AddTrust External CA Root. Ce certificat a été généré en 2000, et c'est son certificat qui a expiré le 30 mai 2020.Pour les validateurs de certificats compétents, y compris les navigateurs modernes, cela n'a pas posé de problème, car ils peuvent eux-mêmes créer une chaîne de confiance avant USERTrust, mais il y avait un problème avec les clients qui utilisent OpenSSL 1.0.x ou GnuTLS. Même si ces clients font confiance à l'autorité de certification racine USERTrust et souhaitent y créer une chaîne, ils se retrouvent toujours avec une chaîne vers AddTrust External CA Root, ce qui entraîne l'échec de la vérification des certificats.Sectigo a fourni un autre certificat intermédiaire croisé signé AAA Certificate Services , qui sera valable jusqu'en 2028.Vérification de vos services
Les opérateurs de gestionnaire de serveur et d'application client sont encouragés à rechercher dans leur chaîne de certificats un certificat racine AddTrust obsolète.Essentiellement, il vous suffit de supprimer la racine de l'autorité de certification externe AddTrust de la chaîne de confiance.Pour les opérateurs de serveurs, il existe un service Qu'est-ce que My Chain Cert? , qui effectue cette vérification et permet de générer une nouvelle chaîne de confiance avec tous les certificats intermédiaires nécessaires. Il n'est pas nécessaire d'inclure un certificat racine dans cette chaîne, car tous les clients l'ont déjà dans le magasin. De plus, l'inclure dans la chaîne est tout simplement inefficace en raison de l'augmentation de la taille de la négociation SSL.Il est conseillé aux opérateurs d'applications clientes de mettre à niveau vers la dernière bibliothèque TLS. Si cela n'est pas possible, vous devez supprimer le certificat racine de l'autorité de certification externe AddTrust de votre stockage. S'il ne se trouve pas dans le référentiel, la chaîne de confiance correcte est créée pour le nouveau certificat racine USERTrust RSA Certification Authority, afin que la vérification TLS passe correctement.Pour supprimer AddTrust External CA Root, vous devez procéder comme suit :- Modifier
/etc/ca-certificates.confet commentermozilla/AddTrust_External_Root.crt
- Courir
update-ca-certificates
Pour résoudre le problème, Fedora et RHEL suggèrent d' ajouter le certificat AddTrust à la liste noire: 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
Mais cette méthode ne fonctionne pas pour GnuTLS.Voir aussi:
« Le problème des certificats Sectigo après le 30 mai 2020 et la méthode de solution » sur le blog d'entreprise Habr
Solutions PKI pour votre entreprise. Contactez-nous au +7 (499) 678 2210, sales-ru@globalsign.com.