De veroudering van het rootcertificaat AddTrust leidde tot storingen in systemen met OpenSSL en GnuTLS

Op 30 mei is de 20-jarige geldigheidsduur van het rootcertificaat verlopen. AddTrust, die gebruik gemaakt van om een cross-signed handtekening te genereren in de certificaten van een van de grootste certificeringsinstanties Sectigo (Comodo). De cross-signed handtekening maakte compatibiliteit mogelijk met verouderde apparaten waarvan de nieuwe rootcertificaat USERTrust niet was toegevoegd aan de opslag van rootcertificaten.

In theorie zou het vervallen van het rootcertificaat AddTrust slechts leiden tot incompatibiliteit met verouderde systemen (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, enz.), omdat het tweede rootcertificaat, dat in de cross-signed handtekening wordt gebruikt, nog steeds actueel is en moderne browsers dit meenemen bij het controleren van de vertrouwensketen. In de praktijk zijn er problemen ontdekt met de controle van de cross-signed handtekening in TLS-clienten die geen browsers gebruiken, waaronder op basis van OpenSSL 1.0.x en GnuTLS. Veilige verbindingen konden niet meer tot stand worden gebracht, met een foutmelding over het verstrijken van het certificaat, als op de server een Sectigo-certificaat werd gebruikt dat in een vertrouwensketen was verbonden met het rootcertificaat AddTrust.

Als gebruikers van moderne browsers de veroudering van het rootcertificaat AddTrust niet opmerkte bij de verwerking van cross-signed certificaten van Sectigo, begonnen er in verschillende externe applicaties en serververwerkingssystemen problemen op te duiken, wat leidde tot tot schending uitval van veel infrastructuren die versleutelde communicatiekanalen gebruikten voor interactie tussen componenten.

Bijvoorbeeld ontstonden er van het probleem problemen met de toegang tot bepaalde pakket repositories in Debian en Ubuntu (apt gaf een foutmelding bij de certificaatcontrole), faalden scripts die gebruik maakten van de tools 'curl' en 'wget', en werden er fouten waargenomen bij het gebruik van Git, de werking van de Roku streaming platformen werd verstoord, en handlers werden niet meer aangeroepen voor Stripe en DataDog, en er begonnen crashes op te treden in Heroku-applicaties, stopten OpenLDAP-cliënten met verbinden, er waren problemen met het verzenden van e-mails naar SMTPS- en SMTP-servers met STARTTLS. Bovendien waren er problemen in verschillende Ruby-, PHP- en Python-scripts die de http-clientmodule gebruikten. Van de browsers vertoont aan Epiphany problemen, waarin de advertentieblokkadelijsten niet meer konden worden geladen.

Programma's in de Go-taal zijn niet onderhevig aan het probleem, omdat in Go wordt voorgesteld een eigen implementatie TLS.

Er werd aangenomen, omdat het probleem oudere versies van distributies raakt (waaronder Debian 9, Ubuntu 16.04, RHEL 6/7) waarin problematische versies van OpenSSL worden gebruikt, maar het probleem kwam ook voor bij het gebruik van de APT-pakketbeheerder in de huidige versies van Debian 10 en Ubuntu 18.04/20.04, omdat APT de GnuTLS-bibliotheek gebruikt. De kern van het probleem is dat veel TLS/SSL-bibliotheken het certificaat als een lineaire keten parseren, terwijl volgens RFC 4158 het certificaat een gerichte, gedistribueerde cyclische grafiek met meerdere vertrouwensankers kan zijn, die in aanmerking moeten worden genomen. Deze tekortkoming in OpenSSL en GnuTLS hebben is bekend bestaat al vele jaren. In OpenSSL is het probleem verholpen in versie 1.1.1, terwijl in GnuTLS blijft de onopgeloste.

Als tijdelijke oplossing wordt voorgesteld om het certificaat 'AddTrust External CA Root' uit de systeemopslag te verwijderen (bijvoorbeeld uit /etc/ca-certificates.conf en /etc/ssl/certs, en daarna 'update-ca-certificates -f -v' uit te voeren), waarna OpenSSL weer normaal kan omgaan met kruisgewijs ondertekende certificaten waarin het is betrokken. Bij het gebruik van de APT-pakketbeheerder kan de certificaatcontrole voor bepaalde verzoeken op eigen risico worden uitgeschakeld (bijvoorbeeld 'apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false').

Om het probleem te blokkeren in Fedora en RHEL wordt voorgesteld om het AddTrust-certificaat op de zwarte lijst te zetten:

trust dump —filter «pkcs11:id=;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Maar deze methode niet werkt werkt nog steeds niet voor GnuTLS (bijvoorbeeld wordt er nog steeds een certificaatverificatiefout weergegeven bij het starten van de wget-tool).

Aan de serverzijde kan men de volgorde van de certificaten in de vertrouwenskete die door de server naar de client wordt verzonden (als het certificaat dat verband houdt met 'AddTrust External CA Root' uit de lijst wordt verwijderd, zal de controle door de client succesvol zijn). Voor de controle en generatie van een nieuwe vertrouwenskete kan de service whatsmychaincert.com worden gebruikt. Sectigo heeft ookeen alternatief kruisgewijs ondertekend tussentijds certificaat ' AAA Certificate Services ' geleverd, dat geldig zal zijn tot 2028 en compatibiliteit met oudere versies van de OS mogelijk maakt.Aanvulling: Het probleem doet zich ook voorin LibreSSL.

Op 30 mei is de 20-jarige geldigheid van het rootcertificaat AddTrust verlopen, dat verschijnt 🥇De veroudering van het rootcertificaat AddTrust leidde tot fouten in systemen met OpenSSL en GnuTLS | ProHoster

Bron: opennet.ru