Varje gång du klickar på hänglåset i din webbläsare litar du på att webbplatsen är den den utger sig för att vara. Under lång tid fanns det en allvarlig lucka i den förtroendet, och den luckan var felaktigt utfärdande av certifikat. Certifikattransparens (CT) byggdes för att åtgärda det problemet, och idag är det kärnan i hur Chrome, Safari och andra moderna webbläsare avgör om de ska lita på ett SSL/TLS-certifikat.
Den här artikeln förklarar vad certifikattransparens är, varför det skapades, hur det fungerar och vad din organisation behöver veta för att följa reglerna och vara skyddad.
Vad är certifikattransparens (CT)?
Certifikattransparens är ett öppet ramverk, ursprungligen föreslaget av Google 2013 och standardiserat i RFC 6962. Det gör utfärdandet av SSL/TLS-certifikat offentligt granskningsbart. Enkelt uttryckt svarar CT på en viktig fråga: hur vet du att en certifikatutfärdare (CA) har utfärdat ett certifikat för din domän på ett legitimt sätt och inte av misstag eller genom kompromiss?
Innan CT existerade kunde en CA utfärda ett certifikat för vilken domän som helst utan att domänägaren någonsin visste om det. En angripare som lyckades lura eller kompromettera en CA kunde få ett giltigt certifikat för google.com eller yourbank.com, och webbläsare skulle lita på det utan att ifrågasätta. DigiNotar-intrånget 2011 gjorde detta hot mycket verkligt, då angripare fick tag på bedrägliga certifikat för stora domäner, inklusive Google.
Certifikattransparens löser detta genom att kräva att alla offentligt betrodda certifikat registreras i en offentlig logg för endast tillägg innan webbläsare litar på dem. Detta gör certifikatutfärdande från en privat handling till en offentligt verifierbar sådan.
Varför infördes certifikattransparens?
PKI -modellen (Public Key Infrastructure) fungerar på en förtroendekedja. Webbläsare litar på en uppsättning rotcertifikatutfärdare. Dessa certifikatutfärdare utfärdar certifikat till webbplatser, och webbläsare accepterar dem. I teorin fungerar detta bra, men i praktiken skapade det en svag länk, nämligen certifikatutfärdarna själva.
DigiNotar-incidenten var inte en engångsföreteelse. Felaktiga certifikatutfärdanden, på grund av oaktsamhet, mänskliga fel eller kompromisser, inträffade hos flera certifikatutfärdare under åren. Det verkliga problemet var inte bara att felaktiga certifikat utfärdades. Problemet var att ingen utanför certifikatutfärdaren kände till dem. Domänägare hade ingen insyn, säkerhetsforskare hade inget sätt att granska och webbläsare hade inget sätt att upptäcka bedrägeriet i tid.
Certifikattransparens stängde den ansvarsbristen. Genom att kräva att alla certifikat loggas offentligt blir alla felaktigt utfärdade certifikat snabbt synliga för domänägare, säkerhetsforskare och webbläsare, innan de kan orsaka verklig skada.
Så fungerar loggar för certifikattransparens
Motorn bakom certifikattransparens är CT-loggen, en offentligt tillgänglig huvudbok med endast tillägg som registrerar varje certifikat som skickas till den. Tänk på det som en notarie för internetcertifikat. Så här fungerar processen:
- Certifikatutfärdande: En CA utfärdar ett SSL/TLS-certifikat för en domän. Certifikatet eller ett förcertifikat skickas till en eller flera CT-loggar före eller strax efter utfärdandet.
- Logginmatning och SCT: Loggservern accepterar inlämningen och returnerar en tidsstämpel för signerat certifikat (SCT), vilket är ett kryptografiskt signerat kvitto som bevisar att certifikatet loggades vid en viss tidpunkt.
- Merkle-trädstruktur: CT-loggar använder ett Merkle-hashträd för att registrera certifikat i en manipulationssäker struktur. Varje post är kryptografiskt kedjad till de föregående, så alla försök att ändra eller ta bort en historisk post är omedelbart upptäckbara.
- Endast tilläggsbaserad tillämpning: Loggar kan endast läggas till. Certifikat kan läggas till men aldrig tas bort. Det betyder att det inte finns något sätt för en certifikatutfärdare att i tysthet radera bevis på ett felaktigt utfärdat certifikat.
- Allmän tillgänglighet: CT-loggar är öppna för alla. Forskare, domänägare och säkerhetsverktyg kan fråga dem för att se alla certifikat som loggas för en domän.
Det finns idag flera CT-loggar, som drivs av Google, Cloudflare, DigiCert och andra. Webbläsare har en lista över betrodda loggar, och endast SCT:er från dessa godkända loggar räknas mot CT-efterlevnad.
Förstå tidsstämplar för signerade certifikat (SCT)
En tidsstämpel för ett signerat certifikat (SCT) är det kryptografiska beviset på att ett certifikat har skickats till en CT-logg. Det är vad webbläsaren kontrollerar för att bekräfta att certifikatet loggades offentligt innan den godkänner att anslutningen litas på.
En SCT innehåller tre saker: logg-ID:t som identifierar vilken CT-logg som utfärdat den, en tidsstämpel som visar när certifikatet loggades och en digital signatur från loggen som bekräftar att posten är äkta. SCT:er kan levereras till webbläsare på tre sätt: inbäddade direkt i själva certifikatet, inkluderade i TLS-handskakningen via en TLS-tillägg eller tillhandahållas via OCSP- häftning. De flesta moderna certifikatutfärdare bäddar in SCT:er direkt vid utfärdandetillfället, så processen är osynlig för serveroperatörer.
Webbläsare kräver vanligtvis två eller flera SCT:er från separata, godkända loggar. Denna redundans innebär att även om en logg försvinner eller blir misstrodd, kan CT-efterlevnad fortfarande verifieras från de återstående SCT:erna.
Varför Chrome och Safari kräver certifikattransparens
Google Chrome började kräva efterlevnad av CT-krav för alla offentligt betrodda certifikat i april 2018. Apples Safari följde kort därefter upp med sin egen CT-policy som omfattade alla certifikat som utfärdats efter den 15 oktober 2018. Dessa var inte godtyckliga beslut. De kom efter år av dokumenterade CA-misslyckanden och ett erkännande av att frivilligt införande av CT var för långsamt.
Om ett certifikat inte innehåller giltiga SCT:er från webbläsarbetrodda loggar visar Chrome och Safari ett certifikatfel. Webbplatsen visas som obetrodd, varningar visas för användare och i företagsmiljöer kan automatiserade system blockera anslutningen helt.
Ett certifikat utan giltiga SCT:er behandlas på samma sätt som ett utgånget eller självsignerat certifikat av Chrome och Safari. För företag innebär det trasiga arbetsflöden, förlorade intäkter och skadat kundförtroende.
CT-kraven från Chrome och Safari drev också hela CA-ekosystemet att följa dem. Alla CA:er som vill fortsätta att vara betrodda av dessa webbläsare måste skicka in certifikat till CT-loggar, vilket gör CT-deltagande till ett icke-förhandlingsbart krav för att verka inom PKI-området. Observera att CT-krav endast gäller offentligt betrodda certifikat. Interna certifikat utfärdade av privata CA:er för intranätanvändning är undantagna från webbläsar-CT-krav, även om övervakning av intern PKI med CT-liknande loggning i allt högre grad rekommenderas som en bästa säkerhetspraxis.
Hur krypteringskonsulting kan hjälpa
Certifikattransparens ger din organisation insyn i vilka certifikat som har utfärdats för dina domäner. Men den insynen blir bara användbar om någon faktiskt tittar på. De flesta säkerhetsteam har inte tid eller verktyg för att aktivt övervaka CT-loggar vid sidan av allt annat de hanterar. Det är den luckan som CertSecure Manager är byggd för att täcka.
CertSecure Manager är Encryption Consultings plattform för hantering av certifikatlivscykeln. Förutom att hantera ditt eget certifikatlager ger det ditt team de upptäckts- och övervakningsfunktioner som gör CT genuint användbart snarare än bara en kryssruta för efterlevnad.
Här är var det direkt stöder:
- Certifikatupptäckt i din miljö: CertSecure Manager skannar din infrastruktur för att bygga en komplett och aktuell inventering av alla SSL/TLS-certifikat som är kopplade till dina domäner, inklusive certifikat som du kanske inte vet har utfärdats. Om ett obehörigt certifikat dyker upp vill du veta om det innan en angripare använder det.
- Automatisering av utgångs- och förnyelsedatum: CT-efterlevnad kräver giltiga SCT:er från webbläsarbetrodda loggar. Det kravet återställs varje gång ett certifikat förnyas. CertSecure Manager automatiserar förnyelseprocessen, så att dina certifikat alltid är aktuella, alltid CT-kompatibla och aldrig lämnas att löpa ut i tysthet.
- Revisionsspår och efterlevnadsrapportering: Varje certifikathändelse, utfärdande, förnyelse och återkallelse loggas i CertSecure Manager, vilket ger dig den dokumentation som dina säkerhets- och efterlevnadsteam behöver när frågor uppstår.
- Centraliserad synlighet: Att hantera certifikat över flera domäner, miljöer och team utan en centraliserad plattform innebär att man måste förlita sig på kalkylblad och kalenderpåminnelser. CertSecure Manager ersätter det med en enda, strukturerad vy över hela din certifikatmiljö.
CT-loggar är offentliga. Det betyder att certifikaten som utfärdats för dina domäner är synliga för alla, inklusive angripare som letar efter möjligheter. Att ha rätt verktyg för att övervaka och hantera ditt certifikatlandskap är inte längre valfritt.
Slutsats
Certifikattransparens är en av de få säkerhetstekniker som faktiskt levererade vad den utlovade. Den förvandlade certifikatutfärdande från en ogenomskinlig process till något offentligt verifierbart och manipulationssäkert. Med Chrome och Safari som tillämpar certifikattransparenskrav är efterlevnad helt enkelt en baslinje för alla organisationer som verkar på det offentliga internet.
Men efterlevnad ensamt räcker inte. Organisationer som behandlar CT som bara en kryssruta missar dess mest användbara funktion, vilket är möjligheten att övervaka loggar för obehöriga certifikat och agera innan skada uppstår. I en miljö där angripare är sofistikerade och kompromisser i leveranskedjan är vanliga är den tidiga varningsförmågan viktig.
