Webbläsare och certifikatvalidering

Beskrivning

HTTPS (via SSL /TLS) använder kryptering av offentlig nyckel för att skydda webbläsarkommunikation från att läsas eller ändras i transit via Internet. Servrar ger besökande webbläsare en offentlig nyckel som används för att upprätta en krypterad anslutning för alla efterföljande datautbyten.

Men bara att få en arbetssätt offentlig nyckel ensam garanterar inte att den (och i serverns förlängning) ägs av rätt fjärrkontroll ämne (dvs. person, företag eller organisation). Man-in-the-middle angripare kan manipulera nätverk för att tjäna sina egna nycklar och därigenom äventyra all kommunikation.

Webbläsare förhindrar detta genom autentiserande HTTPS-servrar som använder certifikat, som är digitala dokument som binda en offentlig nyckel till ett enskilt subjekt. Bindningen görs gällande genom att ha en betrodd ccertifieringsmyndighet (CA) som SSL.com verifiera identiteten för potentiella certifikatägare, via automatiserade och manuella kontroller mot kvalificerade databaser.

Denna förtroenderelation innebär att webbanvändarnas säkerhet inte är absolut; snarare kräver den att användarna litar på webbläsare och certifikatutfärdare för att skydda deras säkerhet. Därför ligger det i varje användares intresse att ha en grundläggande förståelse för hur certifikatvalidering fungerar.

Observera att certifikatvalideringsprocessen (beskrivs i detalj i standarddokumentet RFC 5280) är ganska invecklad. I den här artikeln kommer vi att försöka gå dig längs en väg (en webbläsare som validerar värdens SSL /TLS certifikat) och navigera förbi komplexa detaljer som är opåverkade för de flesta användare.

Obs: Från augusti 2024 RFC 9618, ett dokument från Internet Engineering Task Force (IETF), har uppdaterat algoritmen för att validera policybegränsningar i digitala X.509-certifikat från RFC 5280.

Certifikat och X.509-format

Certifikat är digitala filer i alla avseenden, vilket innebär att de måste följa ett filformat för att lagra information (t.ex. signaturer, nycklar, utfärdare etc.). Medan privata PKI konfigurationer kan implementera vilket format som helst för sina certifikat, betrodda offentligt PKIs (dvs. de som webbläsarna litar på) måste följa RFC 5280, vilket kräver användning av X.509 v3 format.

X.509 v3 tillåter certifikat att inkludera ytterligare data, till exempel användningsbegränsningar eller policyinformation, som förlängningar, där varje tillägg är antingen kritisk or icke kritisk. Om en klient stöter på ett okänt, icke-kritiskt tillägg kan den ignorera det. Om ett tillägg är kritiskt och okänt eller inte kan bearbetas måste certifikatet avvisas.

Certifieringsvägar och vägbearbetning

CA:er använder en privat nyckel för att kryptografiskt signera alla utfärdade certifikat. Sådana signaturer kan kryptografiskt bevisa att ett certifikat utfärdades av en specifik CA och att det inte ändrades efter att det undertecknades.

CA: s fastställer ägande av sin signeringsnyckel genom att inneha ett självutgivet certifikat (kallat rot) för motsvarande publika nyckel. CA:er måste följa noggrant kontrollerade och granskade procedurer för att skapa, hantera och använda en rot, och för att minimera exponeringen använder de normalt en rot för att utfärda mellanliggande certifikat. Dessa mellanhänder kan sedan användas för att utfärda sina kunders certifikat. Ett rot-CA-certifikat är självsignerat och den privata nyckeln skyddas enligt strikta procedurer. Utfärdande sker vanligtvis via mellanhänder, inte direkt från root-certifikatet.

Webbläsare levereras med en inbyggd lista över pålitliga rötter. (Dessa är rötter från certifikatutfärdare som har passerat webbläsarens stränga kriterier för införande.) För att verifiera ett certifikat kommer en webbläsare att få en sekvens av certifikat, var och en har undertecknat nästa certifikat i sekvensen, som kopplar den signerande CA: s rot till servern certifikat.

Denna sekvens av certifikat kallas a certifieringsväg. Banans rot kallas a förtroendeankare och serverns certifikat kallas blad or slutenhet certifikat.

Sökvägskonstruktion

Webbläsare och programvaruklienter i allmänhet kan ofta bygga mot flera kandidatförtroendeankare (t.ex. på grund av korstecken) och hämta ofta saknade mellanliggande certifikat via AIA för att slutföra en kedja. Även om en sökväg kan innehålla certifikat som "kedjas" samman korrekt till ett känt ankare, kan själva sökvägen avvisas på grund av begränsningar för sökvägslängd, domännamn, certifikatanvändning eller policy.

Att konstruera och utvärdera alla möjliga vägar är en dyr process som utförs för varje nytt certifikat som en webbläsare stöter på. Webbläsare har implementerat olika optimeringar för att minimera antalet avvisade kandidatvägar, men att gå in i sådana detaljer ligger långt utanför denna artikel.

Vägvalidering

Efter att en kandidatcertifieringsväg har konstruerats validerar webbläsare den med informationen i certifikaten. En sökväg är giltig om webbläsare kan kryptografiskt bevisa att, med utgångspunkt från ett certifikat som direkt undertecknats av ett förtroendeankare, användes varje certifikats motsvarande privata nyckel för att utfärda nästa i sökvägen, hela vägen ner till bladcertifikatet.

Grundkraven kräver att subjekt- och utfärdarnamnen överallt alla möjliga vägar be byte-för-byte identisk, vilket förenklar tillförlitlig vägbyggande.

Certifieringsväg Valideringsalgoritm

Som tidigare nämnts, från och med augusti 2024, RFC 9618, ett dokument från Internet Engineering Task Force (IETF), har uppdaterat algoritmen för att validera policybegränsningar i digitala X.509-certifikat från RFC 5280. I grund och botten itererar webbläsare igenom alla certifikat i sökvägen med början från förtroendeankaret (dvs. rotcertifikatet) och validerar varje certifikats grundläggande information och kritiska tillägg.

Om proceduren avslutas med det sista certifikatet i sökvägen utan fel accepteras sökvägen som giltig. Om fel produceras markeras sökvägen som ogiltig.

Grundläggande certifikatbehandling

Oavsett tillägg måste webbläsare alltid verifiera grundläggande certifikatinformation som signatur eller emittent. Följande avsnitt visar sekvensen av kontroller som webbläsare utför.

1. Webbläsaren verifierar certifikatets integritet

Ocuco-landskapet namnteckning på certifikatet kan verifieras med normal offentlig nyckelkryptografi. Om signaturen är ogiltig, anses certifikatet vara ändrat efter dess utfärdande och avvisas därför.

2. Webbläsaren verifierar certifikatets giltighet

Ett certifikat giltighetsperiod är det tidsintervall under vilket undertecknande CA garanterar att den kommer att behålla information om dess status. Webbläsare avvisar alla certifikat med en giltighetsperiod som slutar före eller börjar efter datum och tid för valideringskontrollen.

3. Webbläsaren kontrollerar certifikatets återkallningsstatus

När ett certifikat utfärdas förväntas det vara i bruk under hela giltighetsperioden. Naturligtvis kan olika omständigheter göra att ett certifikat blir ogiltigt innan det naturligtvis löper ut.

Sådana omständigheter kan innefatta ett ämne som byter namn eller en misstänkt kompromiss med sin privata nyckel. I fall som detta måste en CA återkalla motsvarande certifikat, och användare litar också på en CA för att meddela webbläsare om deras certifikats återkallningsstatus.

Certifikatåterkallande listor (CRL)

Certifikatåterkallningslistor (CRL:er) har blivit branschstandarden för kontroll av certifikatåterkallelser från och med 2024. CA:er utfärdar regelbundet signerade, tidsstämplade listor över återkallade certifikat som webbläsare kan ladda ner och cacha lokalt.

Även om CRL:er tidigare ansågs vara mindre effektiva än metoder för kontroll i realtid, har branschen insett betydande fördelar som gör dem till den föredragna metoden:

• Förbättrad sekretessCRL:er skyddar användarnas integritet genom att eliminera behovet av att fråga externa servrar om specifika certifikat, vilket kan avslöja surfmönster.
• Operativ effektivitetCA:er kan hantera återkallelser mer effektivt utan att upprätthålla högtillgängliga svarstjänster i realtid
• Minskade infrastrukturkostnaderAtt eliminera behovet av OCSP-personal dygnet runt minskar de operativa kostnaderna avsevärt.
• Bättre cachningModerna webbläsare kan effektivt cachelagra och uppdatera CRL:er, vilket minimerar latensproblemen som tidigare gynnade realtidsmetoder.

Från och med mars 2024, CA/Browser Forum kräver att alla offentligt betrodda CA:er tillhandahåller CRL:er, samtidigt som andra återkallelsemetoder är valfria.Vissa större certifikatutfärdare har avvecklat alternativa återkallningstjänster till förmån för metoder endast med CRL.

Online -certifikatstatusprotokoll (OCSP)

Online Certificate Status Protocol (OCSP), som beskrivs i RFC 6960, utformades för att tillhandahålla kontroll av återkallelse av certifikat i realtid genom att låta webbläsare fråga OCSP-servrar (svarare) om specifika certifikat. Även om OCSP antogs i stor utsträckning under 2010-talet som en förbättring jämfört med regelbundna CRL-nedladdningar, har branschen till stor del övergett denna metod.

• OCSP är nu valfritt för offentligt betrodda CA:er (gäller från och med mars 2024). OCSP:s betydelse är minskande; till exempel, Låt oss kryptera tog bort OCSP-URL:er i maj 2025 och stängde ner svarare i Augusti 2025.
• Vissa webbläsare har inaktiverat OCSP-kontroll eller implementerat det på sätt som ger minimala säkerhetsfördelar.

OCSP häftningEn variant som kallas OCSP häftning förblir användbar i vissa scenarier, där servrar inkluderar OCSP-svar direkt i TLS handskakning, vilket undviker separata klientfrågor till OCSP-svarare. Detta kräver dock specifik serverkonfiguration. Häftning stöds av de flesta servrar/CDN:er, men dess användbarhet minskar i takt med att stora CA:er drar tillbaka OCSP.

Hur detta faktiskt fungerar idag i webbläsare: Sedan den 15 mars 2024 kräver CA/B-forumet att offentligt betrodda CA:er publicerar CRL:er, medan OCSP är valfritt. Moderna webbläsare frågar vanligtvis inte OCSP eller laddar ner CRL:er per webbplats. Istället använder de aggregerade mekanismer byggda från CA-publicerade CRL:er: Chromes CRLSets och Firefox CRLite levererar snabb, integritetsbevarande återkallningsdata till klienter. Som ett resultat minskar OCSP:s roll på den offentliga webben; till exempel tog Let's Encrypt bort OCSP-URL:er i maj 2025 och stängde ner OCSP-svarare i augusti 2025.

4. Webbläsaren verifierar emittenten

Certifikat är normalt kopplade till två enheter:

1. Ocuco-landskapet utfärdare, som är den enhet som äger signeringsnyckeln och
2. Ocuco-landskapet ämne, som hänvisar till ägaren till den offentliga nyckeln som certifikatet verifierar.

Klienter verifierar att varje certifikat i sökvägen är signerat av föregående certifikats offentliga nyckel och att utfärdar-/ämnesnamnen matchar exakt längs sökvägen. För ökad säkerhet, de flesta PKI Implementeringar verifierar också att utfärdarens nyckel är densamma som den nyckel som signerade det aktuella certifikatet. (Observera att detta inte gäller för förtroendeankaret, eftersom rötterna är självutfärdade – dvs. de har samma utfärdare och ämne.)

Behandling av begränsningar

X.509 v3-formatet låter en CA definiera begränsningar eller begränsningar för hur varje certifikat valideras och används som kritiska tillägg. Varje certifikat i sökvägen kan införa ytterligare begränsningar som alla efterföljande certifikat måste följa.

Certifikatbegränsningar påverkar sällan den genomsnittliga Internetanvändaren, även om de är ganska vanliga i företagets SSL-lösningar. Funktionella begränsningar kan tjäna flera operativa syften, men deras mest betydande användning är att mildra kända säkerhetsproblem.

5. Webbläsaren kontrollerar namnbegränsningar

En privatägd (men allmänt betrodd) mellanliggande CA med lämplig namn begränsningar kan ge en organisation finjusterad kontroll över certifikathantering och utfärdande. Certifikat kan begränsas till en specifik domän eller ett domänträd (dvs. inklusive underdomäner) för ett företags eller en organisations domännamn. Namnbegränsningar används ofta för mellanliggande CA-certifikat som köpts från en offentligt betrodd CA för att förhindra att den mellanliggande CA:n utfärdar helt giltiga certifikat för tredjepartsdomäner (t.ex. google.com).

6. Webbläsaren kontrollerar policybegränsningar

En certifikatpolicy är ett juridiskt dokument som publiceras av en CA, som officiellt beskriver de förfaranden de följer för att utfärda och hantera sina certifikat. CA kan utfärda ett certifikat enligt en eller flera policyer, och länkar till dessa ingår i varje certifikat som utfärdas så att pålitliga parter kan utvärdera dessa policyer innan de beslutar att lita på certifikatet.

Av juridiska och operativa skäl kan certifikat införa begränsningar för vilken policy de kan vara föremål för. Om ett certifikat visar sig innehålla kritiska policybegränsningar måste webbläsare validera dem innan de fortsätter. (Men kritiska politikbegränsningar uppträder emellertid sällan i den verkliga världen och det kommer inte att ses bort från resten av denna artikel.)

7. Webbläsaren kontrollerar grundläggande begränsningar (aka väglängd)

X.509 v3-formatet tillåter utgivare att definiera den maximala söklängd som ett certifikat kan stödja. Detta ger kontroll över hur långt varje certifikat kan placeras i en certifieringsväg. Detta är faktiskt viktigt - webbläsare brukade bortse från certifieringsvägens längd tills en forskare visade, 2009 presentation, hur han använde sin webbplats lövcertifikat för att förfalska ett giltigt certifikat för en stor e-handelswebbplats.

8. Webbläsaren verifierar nyckelanvändning

Tillägget "nyckelanvändning" anger syftet med nyckeln i certifikatet. Exempel på sådana ändamål inkluderar kryptering, signaturer, certifikatsignering och så vidare. Webbläsare avvisar certifikat som bryter mot deras begränsningar för nyckelanvändning, till exempel att stöta på ett servercertifikat med en nyckel som endast är avsedd för CRL-signering.

9. Webbläsaren fortsätter att behandla alla återstående kritiska tillägg

Efter att ha bearbetat tilläggen som nämns ovan fortsätter webbläsarna att validera alla återstående tillägg som det aktuella certifikatet anger som kritiska innan de går vidare till nästa. Om en webbläsare når en stigs bladcertifikat utan fel accepteras sökvägen som giltig. Om några fel uppstår markeras sökvägen som ogiltig och en säker anslutning upprättas inte.

Modern certifikathantering: Kortare livslängd och automatisering

SSL /TLS Branschen har genomgått flera förändringar under senare år, vilket fundamentalt förändrat hur certifikat utfärdas och hanteras. Att förstå dessa förändringar är avgörande för PKI chefer, IT-proffs och/eller någon annan som arbetar med digitala certifikat.

Förkortade giltighetsperioder för certifikat

I april 2025 godkände CA/Browser Forum ett betydelsefullt beslut (Valsedel SC-081v3) för att dramatiskt minska certifikatens giltighetstid i etapper:

• Nuvarande (fram till mars 2026)Maximalt 398 dagar (ungefär 13 månader)
• Mars 15, 2026Maximalt 200 dagar
• Mars 15, 2027Maximalt 100 dagar
• Mars 15, 2029Maximalt 47 dagar

Ändringar i domänkontrollvalidering (DCV)

Vid sidan av certifikatens livslängd krymper även återanvändningsperioden för domänvalideringsinformation:

• mars 2026Maximal återanvändningstid: 200 dagar
• mars 2027Maximal återanvändningstid: 100 dagar
• mars 2029Maximal återanvändningstid: 10 dagar

Det här innebär att organisationer kommer att behöva validera domänägande mycket oftare, vilket gör automatisering avgörande för praktisk certifikathantering.

Varför dessa förändringar är viktiga

Säkerhetsfördelar:

• Kortare certifikatlivslängder minskar risken för exponering när nycklar komprometteras
• Mer frekvent validering säkerställer att domänägandet förblir aktuellt
• Snabbare implementering av säkerhetsförbättringar över hela webben

Operativ påverkan:

• Manuell certifikathantering blir praktiskt taget omöjlig
• Organisationer måste implementera automatiserad hantering av certifikatlivscykeln
• Mer frekvent domänvalideringsprocedurer krävs

Automationskrav

Dessa förändringar gör certifikatautomatisering inte bara fördelaktig utan också avgörande. Organisationer bör noggrant överväga:

• Implementera ACME (Automatisk certifikathanteringsmiljö) eller liknande protokoll
• Distribuera lösningar för hantering av certifikatlivscykeln
• Förbered infrastrukturen för frekventa förnyelser och valideringar
• Förbered dig för övergången till kortare certifikatlivslängder

Integrering av certifikattransparens

Moderna webbläsare kräver eller validerar i allt högre grad loggar för certifikattransparens (CT), vilka tillhandahåller offentliga, granskningsbara register över alla utfärdade certifikat. Detta hjälper till att upptäcka:

• Felaktigt utfärdade certifikat
• Obehörig certifikatutfärdande
• Problem med efterlevnaden av CA:n

Slutsats

Det digitala landskapet är fortfarande ett komplext system av sammankopplade komponenter, och webbläsarsäkerhet fortsätter att vara ett aktivt utvecklingsområde som inkluderar: 

• Kortare livslängd för certifikatBranschen går mot 47-dagars giltighetsperioder för certifikat år 2029, vilket gör automatisering avgörande för praktisk certifikathantering.
• Ändringar av återkallelsemetodenÖvergången från OCSP tillbaka till CRL:er återspeglar branschens prioritering av användarnas integritet och operativ effektivitet.
• Strängare tillsyn av CAWebbläsare har blivit mer aggressiva när det gäller att upprätthålla efterlevnad och ta bort förtroende från underpresterande certifikatutfärdare.

Dessa förändringar representerar ett grundläggande skifte mot mer automatiserad, integritetsmedveten och säkerhetsfokuserad certifikathantering. Organisationer bör börja förbereda sig nu för kortare certifikatlivslängder och automatiserade förnyelseprocesser.

Förtroende fortsätter att spela en viktig roll för att hålla användarna säkra online. Vi uppmuntrar dig att hålla dig informerad om dessa ständigt föränderliga standarder och att granska din certifikatutfärdares policyer och efterlevnadshistorik. Som dessa förändringar visar anpassar sig certifikatekosystemet aktivt för att förbättra säkerheten och integritetsskyddet.

För den senaste informationen om bästa praxis för certifikathantering och SSL.coms tillvägagångssätt för dessa branschförändringar, besök vår sida för jämförelse av certifikat.

Tack för att du valde SSL.com, där vi tror a säkrare Internet är en bättre Internet.