Övervakning av certifikattransparens i den statiska CT-eran

Certifikattransparens (CT) är en offentlig, ständigt tillgänglig registrering av TLS-certifikat som utfärdats för webbplatser. Genom att övervaka dessa offentliga loggar, så kallad övervakning av certifikattransparens, upptäcker säkerhetsteam certifikat som utfärdats för sina domäner och som de aldrig begärt eller godkänt. Två saker ändrades 2026 och påverkar hur detta fungerar. En ny webbläsarregel skärper nu hur och var certifikat måste loggas, och själva loggarna har omdesignats för att vara snabbare och billigare att köra.

Tillsammans innebär dessa förändringar att de verktyg och vanor som många team byggt upp för datortomografiövervakning behöver uppdateras. Den här bloggen går igenom vad som förändrats, varför det är viktigt och hur man bygger en övervakningsmetod som håller 2026 och framåt. Vi börjar från grunderna, så du behöver inte vara datortomografiexpert för att följa med.

Vad certifikattransparens är och varför det är viktigt

Certifikattransparens är ett offentligt loggsystem för TLS-certifikat. Varje gång en certifikatutfärdare utfärdar ett certifikat loggar den certifikatet i en offentlig loggbok med endast tillägg. Vem som helst kan läsa dessa loggar, och det är den öppenheten som gör det möjligt att upptäcka certifikat som inte borde existera.

Innan CT existerade kunde en komprometterad eller misskötande CA i tysthet utfärda ett certifikat för vilken domän som helst, och ingen utanför den CA:n skulle veta. År 2011 komprometterade angripare den nederländska CA:n DigiNotar och utfärdade hundratals bedrägliga certifikat, inklusive ett jokerteckencertifikat för *.google.com. Vid den tidpunkten fanns det ingen offentligt granskbar registrering av certifikatutfärdande, vilket gjorde det svårt för domänägare och webbläsarleverantörer att snabbt upptäcka obehöriga eller felaktigt utfärdade certifikat. CT utformades för att täppa till den luckan.

För säkerhetsteam idag erbjuder CT flera praktiska funktioner. Det låter dig upptäcka certifikat som utfärdats för dina domäner utan din vetskap, upptäcka felaktiga utfärdanden av CA innan de orsakar skada, kartlägga din organisations externa certifikatavtryck, inklusive bortglömda underdomäner, och ta fram revisionsbevis för efterlevnadsprogram som kräver tillsyn av certifikatutfärdande.

Protokollet är standardiserat i RFC 6962 och dess efterföljare RFC 9162 , även om webbläsare i praktiken fortfarande implementerar RFC 6962. Webbläsare, inklusive Chrome och Safari, kräver att certifikat har en Signed Certificate Timestamp (SCT), vilket är loggens kryptografiska bevis på att certifikatet registrerades. Ett certifikat utan en giltig SCT från en igenkänd logg avvisas.

Vad Chromes mandat från juni 2026 ändrade

Chrome har tillämpat CT för certifikat med utökad validering sedan 2015 och för de flesta offentliga certifikat sedan 2018. Uppdateringen av Google Chromes rotprogrampolicy ( version 1.8) den 15 juni 2026 stärker kraven på certifikattransparens och PKI-styrning för alla offentligt betrodda certifikattyper.

CA-ägare måste logga varje TLS-serverautentiseringsprecertifikat till minst en CT-logg som Chrome känner igen som "Användbar" eller "Kvalificerad" innan certifikatet utfärdas. Det exakta antalet obligatoriska SCT:er varierar beroende på certifikatets giltighetsperiod. Chrome kräver två SCT:er för certifikat som är giltiga i mindre än 180 dagar och tre för de som är giltiga i 180 dagar eller längre. Hur som helst förblir det underliggande kravet detsamma, nämligen oberoende verifiering från mer än en loggoperatör.

Chrome utvärderar varje certifikat mot en definierad uppsättning loggtillstånd. En logg kan ha ett av fyra tillstånd som är viktiga för efterlevnad.

• Kvalificerad: Nyligen godkänd av Chrome, och dess SCT:er räknas redan mot CT-efterlevnad.
• Användbar: Fullt erkänd och accepterar nya inskick, så SCT:er räknas oavsett om de är inbäddade eller levererade via TLS-handskakningen.
• Skrivskyddat: Den accepterar inte längre nya certifikat (dess slutliga trädstorlek publiceras) men förblir betrodd, så befintliga SCT:er räknas fortfarande.
• Pensionerad: Används inte längre för nya SCT:er, och endast inbäddade SCT:er som utfärdats före tidsstämpeln för pensioneringen räknas fortfarande.

SCT:er från loggar som inte är i ett erkänt gott skick räknas inte mot efterlevnaden. Certifikat som skickas till loggar som senare inte längre är i gott skick kan därför förlora sin CT-efterlevnadsstatus även efter utfärdande. Chrome 148, släppt 5 maj 2026, tog också bort stödet för SCT:er som levereras via häftade OCSP-svar , vilket innebär att SCT:er nu måste bäddas in i själva certifikatet eller levereras via TLS-handskakningstillägget. Alla distributioner som förlitar sig på OCSP-häftade SCT:er bör utfärdas på nytt.

Certifikat som tidigare förlitade sig på äldre undantag för certifikattransparens eller föråldrade leveransmekanismer för SCT bör granskas för att säkerställa att de fortsätter att uppfylla Chromes nuvarande policy för CT. Mandatet stärker också argumenten för kontinuerlig CT-övervakning, eftersom varje felaktigt utfärdat certifikat nu måste visas i en offentlig logg, vilket gör dessa loggar till en mer pålitlig källa till hotinformation än någonsin tidigare.

Varför den äldre RFC 6962-loggdesignen hade problem i stor skala

Den ursprungliga CT-loggdesignen i RFC 6962 fungerar som en klassisk databasbaserad API-tjänst. När en CA skickar in ett certifikat lagrar loggen det i en databas, uppdaterar ett Merkle-hashträd för att kryptografiskt bekräfta till den nya posten och returnerar en SCT. Övervakare och granskare frågar sedan loggen via REST API-slutpunkter för att hämta poster och verifiera konsekvens.

Den här designen fungerade bra när certifikatvolymerna var hanterbara. Web PKI har vuxit långt bortom den punkten. Enskilda CT-loggar innehåller nu miljarder poster per temporal shard (ett tidssegmenterat segment av en logg som bara innehåller certifikat som löper ut inom ett fast fönster), och databasen bakom varje logg blev en flaskhals. När övervakare försökte läsa stora volymer poster snabbt överbelastade de ofta läsvägen. Loggoperatörer svarade med hastighetsgränser, vilket saktade ner övervakningen och undergrävde CT:s värde som en detekteringsmekanism i nära realtid.

24-timmarsgarantin för maximal sammanslagningsfördröjning var också upprepade gånger i fara. Enligt RFC 6962 kan en logg returnera en SCT omedelbart och har sedan upp till 24 timmar på sig att faktiskt inkludera certifikatet i sitt Merkle-träd. Under perioder med hög belastning var loggarna nära att missa det fönstret, vilket skapade situationer där SCT-löftet inte kunde uppfyllas på ett tillförlitligt sätt. Dessa utmaningar gjorde det tydligt att arkitekturen behövde förändras.

Hur Static CT API och Sunlight fungerar

Static CT API har en fundamentalt annorlunda metod. Istället för att svara på frågor från en livedatabas publicerar en statisk CT-logg all sin data som en hierarki av statiska filer som kallas kakel. Dessa kakel serveras från objektlagring som S3 eller från ett CDN. Ingen serversidesberäkning behövs för läsvägen, vilket är källan till dess effektivitetsvinster.

Sunlight-implementeringen, utvecklad av Filippo Valsorda i samarbete med Let's Encrypt, är den mest spridda realiseringen av denna specifikation. Eftersom läsvägen bara är statiska filer kan den hanteras helt från ett CDN, så monitorer hämtar cachebara plattor istället för att upprepade gånger fråga en livedatabas. Det tar bort flaskhalsen i läsvägen som strypte övervakningen under RFC 6962 och minskar kraftigt bandbredden och beräkningen som en loggoperator måste tillhandahålla.

Skrivvägen förbättrades också. Sunlight batchar inskickningar och integrerar dem i Merkle-trädet innan en SCT returneras. Detta eliminerar den maximala sammanslagningsfördröjningen helt. En SCT utfärdas inte förrän certifikatet har lagts in i trädet, så löftet som SCT:n ger är alltid redan uppfyllt.

Loggen är strukturerad som paneler med 256 poster vardera. Varje panel är en statisk fil som skrivs till objektlagring eller ett lokalt filsystem. Loggen är temporärt shardad, så varje shard accepterar endast certifikat vars NotAfter-datum faller inom ett specifikt fönster, vanligtvis sex månader. Detta begränsar shard-storleken och gör lagringen hanterbar.

Let's Encrypt övergick sina RFC 6962-loggar till skrivskyddad den 30 november 2025 och stängde ner dem helt den 28 februari 2026. Deras produktions-CT-loggar körs nu på Sunlight, med Sycamore och Willow som primära produktionsloggar. Googles TrustFabric-team släppte TesseraCT, en statisk CT API-implementering som erbjuder ett alternativ till den Trillian-baserade CTFE som driver många äldre loggar. Ekosystemet har beslutsamt övergått till denna arkitektur.

Hur CT-övervakning fungerar nu

Hur du samlar in poster beror på loggtypen. De två underavsnitten nedan behandlar övervakning mot äldre RFC 6962-loggar och mot de nyare statiska CT-loggarna.

Övervakning mot RFC 6962-loggar

Med en RFC 6962-logg anropar en övervakare get-entries-slutpunkten med ett start- och slutindex, hämtar certifikatbatchar och flyttar sin position när nya poster anländer. Loggen hanterar poster från en databas och returnerar hela certifikatkedjan med varje post, vilket gör CA-attribution enkel.

Övervakning mot statiska CT-loggar

Med en statisk CT-logg laddar en övervakare ner dataplattor direkt. Varje platta innehåller 256 poster. Övervakaren hämtar varje platta den ännu inte har sett, bearbetar posterna och använder loggens signerade kontrollpunktsfil för att spåra den aktuella trädstorleken. Plattorna är statiska och hanteras från objektlagring, så övervakare kan hämta dem parallellt utan att nå hastighetsgränser.

En praktisk skillnad är kedjehanteringen. RFC 6962-loggar returnerade en fullständig certifikatkedja per post. Statiska CT-loggar kopplar inte en kedja till varje post. Istället publicerar loggen ett utfärdarpaket som innehåller de mellanliggande certifikat som den har accepterat. Övervakare som behöver rekonstruera en fullständig kedja för CA-attribution måste bygga den från detta paket. Detta ökar komplexiteten hos övervakaren men är en avsiktlig avvägning som håller data per post kompakt och bandbreddsreduktionen betydande.

Ur ett övervakningsstrategiperspektiv förblir de kategorier som är värda att spåra konsekventa oavsett loggtyp.

• Nya certifikat utfärdade för domäner du äger, inklusive jokerteckensmatchningar.
• Certifikat från certifikatutfärdare som din organisation inte har auktoriserat.
• Certifikat med giltighetsperioder utanför din försäkring.
• Certifikat som avslöjar underdomäner som du inte känner igen.

Dessa fyra kategorier producerar majoriteten av de mest handlingsbara händelserna.

Verktyg tillgängliga för CT-övervakning

Att övervaka CT-loggar är bara halva jobbet; utdelningen kommer från att agera utifrån det du hittar. Det är där Encryption Consultings CertSecure Manager kommer in i bilden. Det är en plattform som kombinerar CT-loggövervakning med fullständig certifikatlivscykelhantering (CLM). Den skannar kontinuerligt CT-loggar efter certifikat utfärdade mot dina domäner och kontrollerar vart och ett mot din inventering av godkända certifikat. Så ditt team kan undersöka och åtgärda fynd från en enda konsol istället för att pussla ihop separata sök- och varningsverktyg.

Certstream tillhandahåller en realtids-WebSocket-feed av CT-loggposter över alla aktiva loggar. Säkerhetsteam använder den för att bygga filtrerings- och varningspipelines som meddelar team kort efter att ett matchande certifikat visas i certifikattransparensloggarna.

Google har en aktuell lista över erkända CT-övervakningstjänster på certificate.transparency.dev. För team som bygger anpassade monitorer är C2SP static-ct-api-specifikationen den kompletta tekniska referensen för kakelformat och kontrollpunktsstruktur.

Oavsett vilket verktyg ditt team använder är resultatet en ström av certifikathändelser som behöver sorteras och granskas. Utformningen av varningar och integrationen med er incidenthanteringsprocess är lika viktig som själva inmatningspipelinen. Dessa verktyg hanterar inmatning; att korrelera händelser mot ert lager av auktoriserade certifikat och agera utifrån dem är där en CLM- plattform kommer in i bilden.

Hotmönster värda att övervaka

Rådata från datortomografi är inte användbara i sig själva. Effektiv övervakning innebär att veta vilka mönster som indikerar ett verkligt problem.

Obehörig certifikatutfärdande : Ett certifikat utfärdas för din domän av en CA som du inte har någon relation med. Detta kan indikera en kringgång av domänvalidering, en komprometterad CA eller en angripare med tillräcklig DNS-kontroll för att klara automatiserad domänvalidering. Att snabbt upptäcka detta var det ursprungliga syftet med att CT var utformat för.

Skuggcertifikat : Certifikat som utfärdats för infrastruktur som din organisation driver men inte hanterar centralt. Utvecklingsteam som använder personliga CA-konton och certifikat som utfärdats för ohanterade, offentliga underdomäner eller infrastruktur utanför godkända PKI- processer är de vanligaste exemplen. Skuggcertifikat skapar både ett säkerhetsgap och en efterlevnadsrisk.

Exponering för underdomäner : Varje underdomän i ett certifikat är offentligt sökbar i det ögonblick då certifikatet loggas. Staging-miljöer, interna verktyg och produkter före lansering blir synliga så snart de tar emot ett certifikat. Att övervaka dina egna domäner i CT ger dig insyn i denna exponering innan en angripare har den.

Indikatorer för felaktig utfärdande : Certifikat med oväntade alternativa ämnesnamn (SAN), oväntade utfärdare, ovanliga EKU-värden (Extended Key Usage) eller avvikande certifikatfält kan indikera ett CA-policyfel eller avsiktlig manipulation. Automatiserad fältanalys i stor skala gör det möjligt att flagga dessa tillförlitligt.

Nätfiske- och typoöverträdelseinfrastruktur : Angripare får regelbundet certifikat för domäner som visuellt liknar en målorganisations namn. Att övervaka CT för nära matchningar och vanliga ersättningsmönster ger tidig varning om att nätfiskeinfrastruktur håller på att byggas upp.

Att upptäcka dessa mönster i rådata från CT är en sak. Att agera snabbt på dem, inom varje domän du äger, är en annan. Att täppa till den luckan är uppgiften för en CLM -plattform, som omvandlar en ström av CT-varningar till prioriterat arbete som ditt team kan spåra och lösa.

Hur krypteringskonsulting kan hjälpa

Övervakning av certifikattransparens är mest värdefull när den ansluter till en CLM-plattform som kan agera utifrån vad loggarna visar. Att se ett obehörigt certifikat i en CT-logg är bara användbart om ditt team vet vilken certifikatutfärdare som utfärdat det, om det begärdes genom en godkänd process och hur snabbt det kan återkallas och ersättas. Utan en CLM-plattform som tillhandahåller den kontexten producerar CT-aviseringar brus snarare än åtgärder.

Encryption Consultings CertSecure Manager är en leverantörsneutral CLM-plattform utformad för att ge säkerhets- och PKI-team fullständig insyn och kontroll över sin certifikatmiljö. Den upptäcker och inventerar automatiskt certifikat i moln-, lokala och hybridmiljöer, så att ditt team alltid vet vad som finns och var. När en CT-varning utlöses för ett certifikat som redan finns i inventeringen kan den korreleras och bekräftas automatiskt. När den utlöses för något okänt, visar CertSecure Manager det som en omedelbar undersökningspunkt med fullständig utfärdare och distributionskontext.

Utöver identifiering automatiserar CertSecure Manager hela certifikatlivscykeln från registrering och utfärdande till förnyelse och återkallelse. Den tillämpar policybaserad utfärdande över både offentliga och privata certifikatutfärdare, integrerar med DevOps-arbetsflöden och protokoll som ACME och SCEP, och tillhandahåller den revisionsloggning som efterlevnadsramverk inklusive PCI DSS , ISO 27001 och NIST-riktlinjer kräver. För organisationer som uppfyller Chromes mandat från juni 2026 innebär detta att ni kan identifiera exakt vilka certifikat som behöver utfärdas på nytt, dirigera dem via rätt certifikatutfärdare och bekräfta efterlevnad av certifikat utan manuell spårning.

Encryption Consulting erbjuder även PKI-as-a-Service för organisationer som behöver en helt hanterad privat CA, och PQC-rådgivningstjänster . Samma kryptoagilitet som kortare certifikatlivslängder och CT-automation nu kräver är vad organisationer kommer att förlita sig på vid övergången till NIST:s postkvantstandarder ( FIPS 203 , 204 och 205 , slutförda i augusti 2024). I takt med att certifikatlivslängderna fortsätter att förkortas och automatisering blir normen, är det att ha både verktygen och expertisen på plats som skiljer team som behåller kontrollen från de som kämpar med att reagera.

Slutsats

Certifikattransparens gör alla offentligt betrodda certifikat till en offentlig post, och att bevaka den posten är ett av de enklaste sätten att upptäcka certifikat som utfärdats för dina domäner utan ditt godkännande. Det fungerar dock bara om någon faktiskt övervakar loggarna och agerar utifrån vad som visas.

Två saker förändrades 2026. Chrome kräver nu att nästan alla certifikat loggas, och själva loggarna har flyttats till den snabbare och billigare designen för Static CT API. Tillsammans gör de CT-data mer kompletta och enklare att arbeta med, men de innebär också att övervakningen som byggdes för den gamla modellen behöver uppdateras. De team som får ut mest av det behandlar CT-övervakning inte som en fristående varningsström, utan som en del av en bredare CLM-plattform som kan undersöka och agera utifrån vad den hittar.