L'expiration du certificat racine AddTrust a entraîné des pannes dans les systèmes utilisant OpenSSL et GnuTLS

Le 30 mai, la durée de validité de 20 ans du certificat racine a expiré AddTrust, qui on utilisait pour la création d'une signature croisée (cross-signed) dans les certificats de l'un des plus grands centres de certification, Sectigo (Comodo). La signature croisée permettait d'assurer la compatibilité avec les dispositifs obsolètes, dont le magasin de certificats racines n'avait pas intégré le nouveau certificat racine USERTrust.

Théoriquement, l'expiration du certificat racine AddTrust n'aurait dû entraîner qu'une perte de compatibilité avec les systèmes anciens (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), puisque le deuxième certificat racine utilisé dans la signature croisée demeure valide et que les navigateurs modernes en tiennent compte lors de la vérification de la chaîne de confiance. En pratique des problèmes ont été découverts concernant la vérification de la signature croisée dans des clients utilisant TLS dépourvus de navigateur, y compris ceux basés sur OpenSSL 1.0.x et GnuTLS. Une connexion sécurisée a cessé d'être établie avec une erreur indiquant l'obsolescence du certificat, si le serveur utilise un certificat Sectigo lié par une chaîne de confiance au certificat racine AddTrust.

Si les utilisateurs des navigateurs modernes n'ont pas remarqué l'obsolescence du certificat racine AddTrust lors du traitement des certificats signés croisés de Sectigo, divers applications tierces et gestionnaires de serveurs ont commencé à rencontrer des problèmes, ce qui a conduit à violation des interruptions de service de nombreuses infrastructures utilisant des canaux de communication chiffrés pour interagir entre les composants.

Par exemple, il y a eu des difficultés des problèmes avec l'accès à certains dépôts de paquets sous Debian et Ubuntu (apt a commencé à retourner une erreur de vérification du certificat), des échecs sont survenus lors des appels à partir de scripts utilisant les utilitaires « curl » et « wget », et des erreurs ont été observées lors de l'utilisation de Git, perturbant le fonctionnement de la plateforme de streaming Roku, les gestionnaires ont cessé d'être appelés Stripe et DataDog, des plantages ont commencé à se produire dans les applications Heroku, les clients OpenLDAP ont cessé de se connecter, des problèmes ont été constatés avec l'envoi de courriels vers des serveurs SMTPS et SMTP avec STARTTLS. De plus, des problèmes apparaissent dans divers scripts Ruby, PHP et Python utilisant le module avec le client HTTP. Dans les navigateurs, le problème concerne Epiphany, qui ne chargent plus les listes de blocage de publicités. Les programmes écrits en Go ne sont pas affectés par le problème, car Go propose touche TLS.

Il était prévu implémentation propre TLS.

On s'attendait à, que le problème concerne les anciennes versions des distributions (y compris Debian 9, Ubuntu 16.04, RHEL 6/7) qui utilisent des branches problématiques d'OpenSSL, mais le problème s'est manifesté également lors de l'utilisation du gestionnaire de paquets APT dans les versions récentes de Debian 10 et Ubuntu 18.04/20.04, car APT utilise la bibliothèque GnuTLS. Le cœur du problème est que de nombreuses bibliothèques TLS/SSL interprètent le certificat comme une chaîne linéaire, alors que conformément à la RFC 4158, un certificat peut représenter un graphe cyclique orienté distribué avec plusieurs points d'ancrage de confiance qui doivent être pris en compte. Ce manque dans OpenSSL et GnuTLS c'était révélé est connu depuis de nombreuses années. Dans OpenSSL, le problème a été corrigé dans la branche 1.1.1, tandis que dans GnuTLS reste non corrigé.

En tant que solution de contournement, il est proposé de retirer du stockage système le certificat «AddTrust External CA Root» (par exemple, en le supprimant de /etc/ca-certificates.conf et /etc/ssl/certs, puis en exécutant «update-ca-certificates -f -v»), après quoi OpenSSL commencera à traiter normalement les certificats signés de façon croisée impliquant ce certificat. Lors de l'utilisation du gestionnaire de paquets APT à vos risques et périls, il est possible de désactiver la vérification des certificats pour certaines requêtes (par exemple, «apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false»).

Pour bloquer le problème dans Fedora et RHEL il est proposé d'ajouter le certificat AddTrust à la liste noire :

dump de confiance —filtre «pkcs11:id=;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 (par exemple, une erreur de vérification de certificat continue d'apparaître lors du lancement de l'outil wget).

Du côté serveur, il est possible de modifier l'ordre des certificats dans la chaîne de confiance envoyée par le serveur au client (si le certificat lié à «AddTrust External CA Root» est retiré de la liste, la vérification par le client se déroulera avec succès). Pour vérifier et générer une nouvelle chaîne de confiance, on peut utiliser le service whatsmychaincert.com. La société Sectigo a également fournit un certificat intermédiaire signé de manière croisée alternatif «AAA Certificate Services», qui sera valable jusqu'en 2028 et permettra de maintenir la compatibilité avec les anciennes versions des systèmes d'exploitation.

Ajout : Le problème se trouve également se manifeste dans LibreSSL.

Source : opennet.ru