Als een browser een website wil authenticeren, presenteert deze zichzelf met een geldige certificaatketen. Een typische keten wordt hierboven weergegeven en er kunnen meer dan één tussencertificaat zijn. Het minimumaantal certificaten in een geldige keten is drie.
Het rootcertificaat is het hart van de certificeringsinstantie. Het is letterlijk ingebouwd in uw besturingssysteem of browser, het is fysiek aanwezig op uw apparaat. Dit kan niet vanaf de serverzijde worden gewijzigd. Een geforceerde update van het besturingssysteem of de firmware op het apparaat is vereist.
Beveiligingsspecialist Scott Helme , dat de belangrijkste problemen zich zullen voordoen met de Let's Encrypt-certificeringsinstantie, omdat dit tegenwoordig de populairste CA op internet is en het rootcertificaat binnenkort slecht zal worden. De Let's Encrypt-root wijzigen .
De eind- en tussencertificaten van de certificeringsinstantie (CA) worden vanaf de server aan de client geleverd en het basiscertificaat is van de client heeft al, dus met deze verzameling certificaten kan men een keten bouwen en een website authenticeren.
Het probleem is dat elk certificaat een vervaldatum heeft, waarna het vervangen moet worden. Zo zijn ze van plan om vanaf 1 september 2020 een beperking in te voeren op de geldigheidsduur van server-TLS-certificaten in de Safari-browser .
Dit betekent dat we allemaal minimaal elke 12 maanden onze servercertificaten moeten vervangen. Deze beperking geldt alleen voor servercertificaten; it geen is van toepassing op root-CA-certificaten.
CA-certificaten zijn onderworpen aan een andere set regels en hebben daarom verschillende geldigheidslimieten. Het is heel gebruikelijk om tussenliggende certificaten te vinden met een geldigheidsduur van 5 jaar en wortelcertificaten met een levensduur van zelfs 25 jaar!
Er zijn meestal geen problemen met tussenliggende certificaten, omdat deze door de server aan de client worden geleverd, die zelf veel vaker zijn eigen certificaat wijzigt, en dus eenvoudigweg het tussenliggende certificaat vervangt. Het is vrij eenvoudig om het samen met het servercertificaat te vervangen, in tegenstelling tot het root-CA-certificaat.
Zoals we al zeiden, is de root-CA rechtstreeks in het clientapparaat zelf ingebouwd, in het besturingssysteem, de browser of andere software. Het wijzigen van de root-CA valt buiten de controle van de website. Hiervoor is een update op de client vereist, of het nu een besturingssysteem- of software-update is.
Sommige root-CA's bestaan al heel lang, we hebben het over 20-25 jaar. Binnenkort zullen enkele van de oudste root-CA's het einde van hun natuurlijke leven naderen; hun tijd is bijna om. Voor de meesten van ons zal dit helemaal geen probleem zijn, omdat CA's nieuwe rootcertificaten hebben gemaakt en deze al vele jaren over de hele wereld worden gedistribueerd in OS- en browserupdates. Maar als iemand zijn besturingssysteem of browser al heel lang niet heeft bijgewerkt, is dat een probleem.
Deze situatie deed zich voor op 30 mei 2020 om 10:48:38 GMT. Dit is het exacte tijdstip waarop van de Comodo-certificeringsinstantie (Sectigo).
Het werd gebruikt voor kruisondertekening om compatibiliteit te garanderen met oudere apparaten die niet over het nieuwe USERTrust-rootcertificaat in hun winkel beschikken.
Helaas deden zich niet alleen problemen voor in oudere browsers, maar ook in niet-browserclients gebaseerd op OpenSSL 1.0.x, LibreSSL en . Bijvoorbeeld in settopboxen , dienst , in Fortinet, Chargify-applicaties, op het .NET Core 2.0-platform voor Linux en .
Er werd aangenomen dat het probleem alleen oudere systemen zou treffen (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, enz.), aangezien moderne browsers het tweede USERTRust-rootcertificaat kunnen gebruiken. Maar in feite begonnen er storingen in honderden webservices die gebruik maakten van de gratis OpenSSL 1.0.x- en GnuTLS-bibliotheken. Er kon geen beveiligde verbinding meer tot stand worden gebracht met een foutmelding dat het certificaat verouderd was.
Volgende - Laten we coderen
Een ander goed voorbeeld van de komende wijziging in de root-CA is de Let's Encrypt-certificeringsinstantie. Meer ze waren van plan om over te stappen van de Identrust-keten naar hun eigen ISRG Root-keten, maar dit .
"Vanwege zorgen over het gebrek aan adoptie van de ISRG-root op Android-apparaten, hebben we besloten de datum van de native root-overgang te verplaatsen van 8 juli 2019 naar 8 juli 2020", aldus Let's Encrypt in een verklaring.
De datum moest worden uitgesteld vanwege een probleem dat ‘rootpropagatie’ wordt genoemd, of preciezer gezegd, het gebrek aan rootpropagatie, wanneer de root-CA niet erg wijdverspreid is over alle clients.
Let's Encrypt gebruikt momenteel een kruisondertekend tussencertificaat dat is gekoppeld aan de IdenTrust DST Root CA X3. Dit rootcertificaat is in september 2000 uitgegeven en verloopt op 30 september 2021. Tot die tijd is Let's Encrypt van plan te migreren naar zijn eigen zelfondertekende ISRG Root X1.
ISRG-root uitgebracht op 4 juni 2015. Hierna begon het proces van goedkeuring als certificeringsautoriteit, dat eindigde . Vanaf dat moment was de root-CA voor alle clients beschikbaar via een besturingssysteem- of software-update. Het enige dat u hoefde te doen, was de update installeren.
Maar dat is het probleem.
Als uw mobiele telefoon, tv of ander apparaat al twee jaar niet is bijgewerkt, hoe weet deze dan over het nieuwe ISRG Root X1-rootcertificaat? En als u het niet op het systeem installeert, maakt uw apparaat alle Let's Encrypt-servercertificaten ongeldig zodra Let's Encrypt naar een nieuwe root overschakelt. En in het Android-ecosysteem zijn er veel verouderde apparaten die al lange tijd niet zijn bijgewerkt.
Android-ecosysteem
Dit is de reden waarom Let's Encrypt de overstap naar zijn eigen ISRG-root heeft uitgesteld en nog steeds een tussenproduct gebruikt dat doorloopt naar de IdenTrust-root. Maar de transitie zal hoe dan ook gemaakt moeten worden. En de datum van rootverandering wordt toegewezen .
Om te controleren of ISRG X1 root op uw apparaat (tv, settopbox of andere client) is geïnstalleerd, opent u de testsite . Als er geen beveiligingswaarschuwing verschijnt, is alles meestal in orde.
Let's Encrypt is niet de enige die voor de uitdaging staat om naar een nieuwe root te migreren. Cryptografie op internet werd iets meer dan twintig jaar geleden voor het eerst gebruikt, dus dit is het moment waarop veel rootcertificaten op het punt staan te verlopen.
Eigenaren van smart-tv's die de Smart TV-software al jaren niet meer hebben bijgewerkt, kunnen met dit probleem te maken krijgen. Bijvoorbeeld de nieuwe GlobalSign-root werd uitgebracht in 2012, en nadat sommige oude Smart TV's er geen keten aan kunnen bouwen, omdat ze simpelweg niet over deze root-CA beschikken. Deze klanten konden met name geen beveiligde verbinding tot stand brengen met de website bbc.co.uk. Om het probleem op te lossen moesten BBC-beheerders hun toevlucht nemen tot een truc: zij via aanvullende tussencertificaten, gebruikmakend van oude wortels и , die nog niet verrot zijn.
www.bbc.co.uk (blad) GlobalSign ECC OV SSL CA 2018 (gemiddeld) GlobalSign Root CA - R5 (gemiddeld) GlobalSign Root CA - R3 (gemiddeld)
Dit is een tijdelijke oplossing. Het probleem verdwijnt pas als u de clientsoftware bijwerkt. Een smart-tv is in wezen een computer met beperkte functionaliteit en Linux. En zonder updates zullen de rootcertificaten onvermijdelijk rotten.
Dit geldt voor alle apparaten, niet alleen voor tv's. Als u een apparaat heeft dat met internet is verbonden en dat werd geadverteerd als een 'slim' apparaat, dan heeft het probleem met rotte certificaten daar vrijwel zeker betrekking op. Als het apparaat niet wordt bijgewerkt, zal de root-CA-opslag na verloop van tijd verouderd raken en uiteindelijk zal het probleem aan de oppervlakte komen. Hoe snel het probleem optreedt, hangt af van wanneer het rootarchief voor het laatst is bijgewerkt. Dit kan enkele jaren duren vóór de daadwerkelijke releasedatum van het apparaat.
Dit is trouwens het probleem waarom sommige grote mediaplatforms geen gebruik kunnen maken van moderne geautomatiseerde certificeringsinstanties zoals Let's Encrypt, schrijft Scott Helme. Ze zijn niet geschikt voor smart-tv’s en het aantal rooten is te klein om certificaatondersteuning op oudere apparaten te garanderen. Anders kan tv simpelweg geen moderne streamingdiensten lanceren.
Uit het laatste incident met AddTrust is gebleken dat zelfs grote IT-bedrijven niet voorbereid zijn op het feit dat het rootcertificaat verloopt.
Er is maar één oplossing voor het probleem: updaten. Ontwikkelaars van slimme apparaten moeten vooraf een mechanisme bieden voor het updaten van software en rootcertificaten. Aan de andere kant is het voor fabrikanten niet rendabel om de werking van hun apparaten te garanderen nadat de garantieperiode is verstreken.
Bron: www.habr.com