Browsers en certificaatvalidatie

Introductie

HTTPS (via SSL /TLS) toepassingen codering met openbare sleutel om te voorkomen dat browsercommunicatie wordt gelezen of gewijzigd tijdens verzending via internet. Servers bieden bezoekende browsers een openbare sleutel die wordt gebruikt om een ​​gecodeerde verbinding tot stand te brengen voor alle volgende gegevensuitwisselingen.

Echter, gewoon een ontvangen werkzaam publieke sleutel alleen garandeert niet dat deze (en bij uitbreiding de server) inderdaad eigendom is van de juiste afstandsbediening onderwerpen (d.w.z. persoon, bedrijf of organisatie). Man-in-the-middle aanvallers kunnen netwerken manipuleren om hun eigen sleutels te bedienen, waardoor elke communicatie in gevaar komt.

Browsers voorkomen dit door authenticeren HTTPS-servers gebruiken certificaten, dat zijn digitale documenten die binden een publieke sleutel voor een individueel onderwerp. De binding wordt bevestigd door een vertrouwde sleutel te hebben.certificaatautoriteit (CA) zoals SSL.com verifieer de identiteit van potentiële certificaathouders via geautomatiseerde en handmatige controles op basis van gekwalificeerde databases.

Deze vertrouwensrelatie betekent dat de veiligheid van webgebruikers niet absoluut is; gebruikers moeten browsers en CA's vertrouwen om hun veiligheid te beschermen. Daarom is het in het belang van elke gebruiker om een ​​basiskennis te hebben van hoe certificaatvalidatie werkt.

Houd er rekening mee dat het certificaatvalidatieproces (gedetailleerd beschreven in het standaarddocument) RFC 5280) is nogal ingewikkeld. In dit artikel zullen we proberen u langs één pad te leiden (een browser die de SSL /TLS certificaat) en navigeer langs complexe details die voor de meeste gebruikers niet van belang zijn.

Let op: Met ingang van augustus 2024 RFC 9618, een document van de Internet Engineering Task Force (IETF)heeft het algoritme voor het valideren van beleidsbeperkingen in digitale X.509-certificaten bijgewerkt van RFC 5280.

Certificaten en het X.509-formaat

Certificaten zijn in alle opzichten digitale bestanden, wat betekent dat ze een bestandsformaat moeten volgen om informatie op te slaan (bijvoorbeeld handtekeningen, sleutels, uitgevers, enz.). Hoewel ze privé zijn PKI configuraties kunnen elk formaat voor hun certificaten implementeren, openbaar vertrouwd PKIs (d.w.z. die welke door de browsers worden vertrouwd) moeten voldoen aan RFC 5280, die het gebruik van de X.509 v3 formaat.

Met X.509 v3 kunnen certificaten aanvullende gegevens bevatten, zoals gebruiksbeperkingen of beleidsinformatie extensies, waarbij elke extensie een van beide is kritisch or niet kritisch. Als een client een niet-herkende, niet-kritieke extensie tegenkomt, kan deze worden genegeerd. Als een extensie kritiek is en niet wordt herkend of niet kan worden verwerkt, moet het certificaat worden afgewezen.

Certificeringspaden en padverwerking

CA's gebruiken een privésleutel om alle uitgegeven certificaten cryptografisch te ondertekenen. Dergelijke handtekeningen kunnen cryptografisch bewijzen dat een certificaat is uitgegeven door een specifieke CA en dat het niet is gewijzigd nadat het was ondertekend.

CA's stellen het eigendom van hun ondertekeningssleutel vast door in het bezit te zijn van een zelf afgegeven certificaat (de wortel) voor de bijbehorende openbare sleutel. CA's moeten strikt gecontroleerde en gecontroleerde procedures volgen om een ​​root te creëren, beheren en gebruiken. Om de blootstelling te minimaliseren, zullen ze normaal gesproken een root gebruiken om tussen- certificaten. Deze tussenpersonen kunnen vervolgens worden gebruikt om de certificaten voor hun klanten uit te geven. Een root-CA-certificaat is zelfondertekend en de privésleutel wordt beschermd volgens strenge procedures. Uitgifte vindt doorgaans plaats via tussenpersonen, niet rechtstreeks vanuit de roots.

Browsers worden geleverd met een ingebouwde lijst met vertrouwde roots. (Dit zijn roots van CA's die voldoen aan de strikte criteria van de browser voor opname.) Om een ​​certificaat te verifiëren, verkrijgt een browser een reeks certificaten, die elk het volgende certificaat in de reeks hebben ondertekend, waardoor de root van de ondertekenende CA wordt verbonden met die van de server. certificaat.

Deze reeks certificaten wordt a genoemd certificeringspad. De wortel van het pad wordt een vertrouw anker en het servercertificaat heet het blad or eind entiteit certificaat.

Pad constructie

Webbrowsers en softwareclients bouwen vaak meerdere kandidaat-vertrouwensankers op (bijvoorbeeld door middel van kruistekens) en halen ontbrekende tussenliggende waarden op via AIA om een ​​keten te voltooien. Hoewel een pad certificaten kan bevatten die correct aan een bekend anker worden gekoppeld, kan het pad zelf worden afgewezen vanwege beperkingen op de padlengte, domeinnaam, certificaatgebruik of beleid.

Het bouwen en evalueren van alle mogelijke paden is een kostbaar proces dat wordt uitgevoerd voor elk nieuw certificaat dat een browser tegenkomt. Browsers hebben verschillende optimalisaties geïmplementeerd om het aantal afgewezen kandidaatpaden te minimaliseren, maar het verdiepen in dergelijke details valt ver buiten het bestek van dit artikel.

Padvalidatie

Nadat een kandidaat-certificeringspad is samengesteld, valideren browsers dit met behulp van de informatie in de certificaten. Een pad is geldig als browsers cryptografisch kunnen bewijzen dat, beginnend bij een certificaat dat rechtstreeks is ondertekend door een trust anchor, de bijbehorende privésleutel van elk certificaat werd gebruikt om de volgende in het pad uit te geven, helemaal tot aan het leaf-certificaat.

De basisvereisten vereisen dat de namen van het onderwerp en de uitgever in alle mogelijke paden be byte-voor-byte identiek, wat het betrouwbaar bouwen van paden vereenvoudigt.

Algoritme voor certificeringspad

Zoals eerder opgemerkt, vanaf augustus 2024, RFC 9618, een document van de Internet Engineering Task Force (IETF)heeft het algoritme voor het valideren van beleidsbeperkingen in digitale X.509-certificaten bijgewerkt van RFC 5280. In principe doorlopen browsers alle certificaten in het pad, te beginnen met het vertrouwde anker (d.w.z. het rootcertificaat), waarbij de basisinformatie en kritieke uitbreidingen van elk certificaat worden gevalideerd.

Als de procedure zonder fouten eindigt met het laatste certificaat in het pad, wordt het pad als geldig geaccepteerd. Als er fouten worden geproduceerd, wordt het pad gemarkeerd als ongeldig.

Basis certificaatverwerking

Ongeacht eventuele extensies, moeten browsers altijd de basiscertificaatgegevens zoals de handtekening of de uitgever verifiëren. De volgende secties tonen de reeks controles die browsers uitvoeren.

1. De browser controleert de integriteit van het certificaat

De handtekening op het certificaat kan worden geverifieerd met behulp van normale openbare sleutelcryptografie. Als de handtekening ongeldig is, wordt het certificaat geacht te zijn gewijzigd na afgifte en wordt het daarom afgewezen.

2. De browser controleert de geldigheid van het certificaat

Een certificaat geldigheidsduur is het tijdsinterval waarin de ondertekenende CA garandeert dat hij informatie over zijn status zal bewaren. Browsers weigeren certificaten met een geldigheidsperiode die eindigt vóór of begint na de datum en tijd van de validatiecontrole.

3. De browser controleert de intrekkingsstatus van het certificaat

Wanneer een certificaat wordt afgegeven, wordt verwacht dat het gedurende de gehele geldigheidsperiode in gebruik is. Natuurlijk kunnen verschillende omstandigheden ertoe leiden dat een certificaat ongeldig wordt voordat het op natuurlijke wijze verloopt.

Dergelijke omstandigheden kunnen een onderwerp zijn dat zijn naam verandert of een vermoedelijke inbreuk op zijn privésleutel. In dergelijke gevallen moet een CA het bijbehorende certificaat intrekken, en gebruikers vertrouwen ook op een CA om browsers op de hoogte te stellen van de intrekkingsstatus van hun certificaten.

Certificaatintrekkingslijsten (CRL)

Sinds 2024 zijn certificaatintrekkingslijsten (CRL's) de industriestandaard voor het controleren van certificaatintrekking. Certificaatautoriteiten geven periodiek ondertekende, van een tijdstempel voorziene lijsten uit met ingetrokken certificaten. Deze lijsten kunnen door browsers worden gedownload en lokaal in de cache worden opgeslagen.

Hoewel CRL's voorheen als minder efficiënt werden beschouwd dan realtime controlemethoden, heeft de sector aanzienlijke voordelen onderkend waardoor ze de voorkeursaanpak zijn:

• Verbeterde privacy:CRL's beschermen de privacy van gebruikers door de noodzaak weg te nemen om externe servers te raadplegen over specifieke certificaten, wat surfpatronen zou kunnen onthullen
• Operationele efficiëntie:CA's kunnen intrekking efficiënter beheren zonder dat ze realtime responsdiensten met hoge beschikbaarheid hoeven te onderhouden
• Lagere infrastructuurkosten:Doordat er geen 24/7 OCSP-responders meer nodig zijn, wordt de operationele overhead aanzienlijk verminderd
• Betere cachingModerne browsers kunnen CRL's efficiënt cachen en bijwerken, waardoor de latentieproblemen die voorheen de voorkeur genoten bij realtimemethoden tot een minimum worden beperkt.

Vanaf maart 2024, Het CA/Browser Forum vereist dat alle publiekelijk vertrouwde CA's CRL's verstrekken, terwijl andere intrekkingsmethoden optioneel worden gemaaktSommige grote certificeringsinstanties zijn gestopt met alternatieve intrekkingsservices ten gunste van CRL-only-benaderingen.

Online Certificaat Status Protocol (OCSP)

Het Online Certificate Status Protocol (OCSP), beschreven in RFC 6960, is ontworpen om realtime certificaatintrekking te controleren door browsers in staat te stellen OCSP-servers (responders) te raadplegen over specifieke certificaten. Hoewel OCSP in de jaren 2010 breed werd geïmplementeerd als een verbetering ten opzichte van periodieke CRL-downloads, is de industrie grotendeels van deze aanpak afgestapt.

• OCSP is nu optioneel voor publiekelijk vertrouwde CA's (vanaf maart 2024). Het belang van OCSP is afnemende; bijvoorbeeld, Laten we versleutelen OCSP-URL's in mei 2025 verwijderd en responders uitgeschakeld in Augustus 2025.
• Sommige browsers hebben OCSP-controle uitgeschakeld of op manieren geïmplementeerd die minimale beveiligingsvoordelen opleveren

OCSP-nieten: Een variant genaamd OCSP-nieten blijft nuttig in sommige scenario's, waarbij servers OCSP-reacties rechtstreeks in de TLS handshake, waardoor afzonderlijke clientquery's naar OCSP-responders worden vermeden. Dit vereist echter een specifieke serverconfiguratie. Stapling wordt door de meeste servers/CDN's ondersteund, maar de bruikbaarheid ervan neemt af naarmate grote CA's OCSP intrekken.

Hoe dit vandaag de dag in browsers werkt: Sinds 15 maart 2024 vereist het CA/B Forum dat openbaar vertrouwde CA's CRL's publiceren, terwijl OCSP optioneel is. Moderne browsers raadplegen OCSP over het algemeen niet en downloaden CRL's niet per site. In plaats daarvan gebruiken ze geaggregeerde mechanismen die zijn opgebouwd uit door CA's gepubliceerde CRL's: CRLSets van Chrome en CRLite van Firefox leveren snelle, privacybeschermende intrekkingsgegevens aan clients. Hierdoor neemt de rol van OCSP op het openbare web af; Let's Encrypt heeft bijvoorbeeld in mei 2025 OCSP-URL's verwijderd en in augustus 2025 OCSP-responders uitgeschakeld.

4. De browser verifieert de uitgever

Certificaten worden normaal gesproken geassocieerd met twee entiteiten:

1. De emittent, wat de entiteit is die de ondertekeningssleutel bezit en
2. De onderwerpen, die verwijst naar de eigenaar van de openbare sleutel die het certificaat verifieert.

Clients controleren of elk certificaat in het pad is ondertekend met de openbare sleutel van het vorige certificaat en of de namen van uitgevers en onderwerpen langs het pad exact overeenkomen. Voor extra veiligheid zijn de meeste PKI Implementaties verifiëren ook of de sleutel van de uitgever dezelfde is als de sleutel waarmee het huidige certificaat is ondertekend. (Merk op dat dit niet geldt voor het vertrouwensanker, aangezien roots zelfuitgegeven zijn – d.w.z. ze hebben dezelfde uitgever en hetzelfde onderwerp.)

Beperking van verwerking

Met de X.509 v3-indeling kan een CA beperkingen of beperkingen definiëren voor de manier waarop elk certificaat wordt gevalideerd en gebruikt als essentiële extensies. Elk certificaat in het pad kan aanvullende beperkingen opleggen waaraan alle volgende certificaten moeten voldoen.

Certificaatbeperkingen hebben zelden invloed op de gemiddelde internetgebruiker, hoewel ze veel voorkomen in zakelijke SSL-oplossingen. Functionele beperkingen kunnen verschillende operationele doeleinden dienen, maar hun belangrijkste gebruik is het wegnemen van bekende beveiligingsproblemen.

5. De browser controleert naambeperkingen

Een particuliere (maar door het publiek vertrouwde) tussenliggende CA met de juiste naambeperkingen Kan een organisatie gedetailleerde controle geven over certificaatbeheer en -uitgifte. Certificaten kunnen worden beperkt tot een specifiek domein of domeinboom (inclusief subdomeinen) voor de domeinnaam van een bedrijf of organisatie. Naambeperkingen worden vaak gebruikt voor certificaten van tussenliggende CA's die zijn gekocht bij een openbaar vertrouwde CA om te voorkomen dat de tussenliggende CA volledig geldige certificaten uitgeeft voor domeinen van derden (bijv. google.com).

6. De browser controleert beleidsbeperkingen

Een certificaatbeleid is een juridisch document dat door een certificeringsinstantie wordt gepubliceerd en waarin de procedures worden beschreven die zij volgen om hun certificaten af ​​te geven en te beheren. CA's kunnen een certificaat afgeven onder een of meer beleidsregels, en links naar deze zijn opgenomen in elk uitgegeven certificaat, zodat vertrouwende partijen dit beleid kunnen evalueren voordat ze besluiten dat certificaat te vertrouwen.

Om juridische en operationele redenen kunnen certificaten beperkingen opleggen aan het beleid waaraan ze kunnen worden onderworpen. Als blijkt dat een certificaat kritische beleidsbeperkingen bevat, moeten browsers deze valideren voordat ze verder kunnen gaan. (Kritieke beleidsbeperkingen worden echter zelden in de echte wereld aangetroffen en zullen daarom voor de rest van dit artikel worden genegeerd.)

7. De browser controleert basisbeperkingen (ook bekend als padlengte)

Met de X.509 v3-indeling kunnen uitgevers de maximale padlengte definiëren die een certificaat kan ondersteunen. Dit geeft controle over hoe ver elk certificaat in een certificeringspad kan worden geplaatst. Dit is eigenlijk belangrijk - browsers negeerden de lengte van het certificeringspad totdat een onderzoeker het aantoonde, in een 2009 presentatie, hoe hij het bladcertificaat van zijn website gebruikte om een ​​geldig certificaat voor een grote e-commercewebsite te vervalsen.

8. De browser controleert het sleutelgebruik

De extensie "sleutelgebruik" vermeldt het doel van de sleutel in het certificaat. Voorbeelden van dergelijke doeleinden zijn onder meer versleuteling, handtekeningen, ondertekening van certificaten, enzovoort. Browsers weigeren certificaten die hun sleutelgebruiksbeperkingen schenden, zoals het tegenkomen van een servercertificaat met een sleutel die alleen bedoeld is voor het ondertekenen van CRL.

9. De browser gaat door met het verwerken van alle resterende kritieke extensies

Na het verwerken van de bovengenoemde extensies, gaan browsers door met het valideren van alle resterende extensies die door het huidige certificaat als kritiek worden bestempeld, voordat ze doorgaan naar de volgende. Als een browser het leaf-certificaat van een pad zonder fouten bereikt, wordt het pad als geldig geaccepteerd. Als er fouten worden gemaakt, wordt het pad gemarkeerd als ongeldig en wordt er geen beveiligde verbinding tot stand gebracht.

Modern certificaatbeheer: kortere levensduur en automatisering

De SSL /TLS De sector heeft de afgelopen jaren verschillende veranderingen ondergaan, waardoor de manier waarop certificaten worden uitgegeven en beheerd fundamenteel is veranderd. Inzicht in deze veranderingen is cruciaal voor PKI managers, IT-professionals en/of iedereen die met digitale certificaten werkt.

Verkorte geldigheidsperiodes van certificaten

In april 2025 keurde het CA/Browser Forum een ​​baanbrekend besluit goed (Stembiljet SC-081v3) om de geldigheidsduur van certificaten gefaseerd drastisch te verkorten:

• Huidig ​​(tot en met maart 2026): Maximaal 398 dagen (ongeveer 13 maanden)
• 15 maart 2026: Maximaal 200 dagen
• 15 maart 2027: Maximaal 100 dagen
• 15 maart 2029: Maximaal 47 dagen

Wijzigingen in Domain Control Validation (DCV)

Naast de levensduur van certificaten wordt ook de hergebruikperiode voor domeinvalidatie-informatie korter:

• Maart 2026: Maximaal 200 dagen hergebruik
• Maart 2027: Maximaal 100 dagen hergebruik
• Maart 2029: Maximaal 10 dagen hergebruik

Dit betekent dat organisaties veel vaker het domeineigendom moeten valideren. Automatisering is daarom essentieel voor praktisch certificaatbeheer.

Waarom deze veranderingen ertoe doen

Beveiligingsvoordelen:

• Kortere certificaatlevensduur verkort de blootstellingsperiode wanneer sleutels worden gecompromitteerd
• Door frequentere validatie blijft het domeineigendom actueel
• Snellere implementatie van beveiligingsverbeteringen op het web

Operationele impact:

• Handmatig certificaatbeheer wordt praktisch onmogelijk
• Organisaties moeten geautomatiseerd certificaatlevenscyclusbeheer implementeren
• Vaker vereiste domeinvalidatieprocedures

Automatiseringsvereisten

Deze veranderingen maken certificaatautomatisering niet alleen nuttig, maar ook essentieel. Organisaties zouden het volgende serieus moeten overwegen:

• Implementeren ACME (Automatische Certificaatbeheeromgeving) of soortgelijke protocollen
• Implementeren oplossingen voor certificaatlevenscyclusbeheer
• Bereid de infrastructuur voor op frequente vernieuwingen en validaties
• Bereid u voor op de overgang naar kortere certificaatlevensduur

Integratie van certificaattransparantie

Moderne browsers vereisen of valideren steeds vaker Certificate Transparency (CT)-logs, die openbare, controleerbare registraties van alle uitgegeven certificaten bieden. Dit helpt bij het detecteren van:

• Verkeerd uitgegeven certificaten
• Ongeautoriseerde certificaatuitgifte
• CA-nalevingsproblemen

Conclusie

Het digitale landschap blijft een complex systeem van onderling verbonden componenten. Browserbeveiliging is een gebied waarop nog steeds actief wordt ontwikkeld, waaronder: 

• Kortere certificaatlevensduurDe sector beweegt zich richting een geldigheidsduur van certificaten van 47 dagen in 2029, waardoor automatisering essentieel wordt voor praktisch certificaatbeheer
• Wijzigingen in de intrekkingsmethode:De verschuiving van OCSP naar CRL's weerspiegelt de prioriteit die de sector geeft aan de privacy van gebruikers en operationele efficiëntie.
• Strengere CA-toezichtBrowsers zijn agressiever geworden in het afdwingen van naleving en het intrekken van het vertrouwen in slecht presterende certificeringsinstanties.

Deze veranderingen vertegenwoordigen een fundamentele verschuiving naar meer geautomatiseerd, privacybewust en beveiligingsgericht certificaatbeheer. Organisaties moeten zich nu al voorbereiden op kortere certificaatlevensduur en geautomatiseerde verlengingsprocessen.

Vertrouwen blijft een belangrijke rol spelen bij de online veiligheid van gebruikers. We raden u aan op de hoogte te blijven van deze veranderende normen en het beleid en de nalevingsgeschiedenis van uw certificeringsinstantie te controleren. Zoals deze veranderingen aantonen, past het certificaatecosysteem zich actief aan om de beveiliging en privacybescherming te verbeteren.

Voor de meest actuele informatie over best practices voor certificaatbeheer en de aanpak van SSL.com ten aanzien van deze veranderingen in de sector, kunt u terecht op onze certificaatvergelijkingspagina.

Bedankt voor het kiezen van SSL.com, waar wij geloven dat veiliger Internet is een beter Internet.