Certificaattransparantiemonitoring in het tijdperk van statische CT-scans

Certificate Transparency (CT) is een openbaar, continu bijgehouden register van de TLS-certificaten die voor websites zijn uitgegeven. Door deze openbare logboeken te controleren, ook wel Certificate Transparency-monitoring genoemd, kunnen beveiligingsteams certificaten opsporen die voor hun domeinen zijn uitgegeven, maar die ze nooit hebben aangevraagd of goedgekeurd. In 2026 zijn er twee dingen veranderd die van invloed zijn op de werking hiervan. Een nieuwe browserregel verscherpt de regels voor hoe en waar certificaten moeten worden gelogd, en de logboeken zelf zijn opnieuw ontworpen om sneller en goedkoper te kunnen worden uitgevoerd.

Deze veranderingen betekenen dat de tools en gewoonten die veel teams hebben ontwikkeld voor CT-monitoring, aan een update toe zijn. Deze blog bespreekt wat er is veranderd, waarom het belangrijk is en hoe je een monitoringaanpak kunt ontwikkelen die ook in 2026 en daarna nog relevant is. We beginnen bij de basis, dus je hoeft geen CT-expert te zijn om mee te kunnen lezen.

Wat certificaattransparantie inhoudt en waarom het belangrijk is

Certificate Transparency (CTT) is een openbaar logboekregistratiesysteem voor TLS-certificaten. Telkens wanneer een certificeringsinstantie een certificaat uitgeeft, registreert deze dat certificaat in een openbaar, alleen-toevoegend register. Iedereen kan deze logboeken lezen, en die transparantie maakt het mogelijk om certificaten te ontdekken die niet zouden mogen bestaan.

Voordat CT bestond, kon een gecompromitteerde of slecht functionerende certificeringsinstantie (CA) stilletjes een certificaat uitgeven voor elk willekeurig domein, zonder dat iemand buiten die CA daarvan op de hoogte was. In 2011 hackten aanvallers de Nederlandse CA DigiNotar en gaven honderden frauduleuze certificaten uit, waaronder een wildcardcertificaat voor *.google.com. Destijds bestond er geen openbaar controleerbaar register van certificaatuitgiften, waardoor het voor domeineigenaren en browserleveranciers moeilijk was om ongeautoriseerde of verkeerd uitgegeven certificaten snel te detecteren. CT is ontworpen om die lacune op te vullen.

Voor beveiligingsteams biedt CT tegenwoordig diverse praktische mogelijkheden. Het stelt u in staat certificaten te detecteren die zonder uw medeweten voor uw domeinen zijn uitgegeven, foutieve certificaatuitgifte door certificeringsinstanties op te sporen voordat dit schade aanricht, de externe certificaatvoetafdruk van uw organisatie in kaart te brengen, inclusief vergeten subdomeinen, en auditbewijs te genereren voor complianceprogramma 's die toezicht op certificaatuitgifte vereisen.

Het protocol is gestandaardiseerd in RFC 6962 en de opvolger daarvan , RFC 9162 , hoewel browsers in de praktijk nog steeds RFC 6962 implementeren. Browsers, waaronder Chrome en Safari, vereisen dat certificaten een Signed Certificate Timestamp (SCT) bevatten, wat het cryptografische bewijs in het logboek is dat het certificaat is geregistreerd. Een certificaat zonder een geldige SCT uit een erkend logboek wordt geweigerd.

Wat de deadline van Chrome in juni 2026 veranderde

Chrome hanteert al sinds 2015 Certificate Transparency (CT) voor certificaten met uitgebreide validatie en sinds 2018 voor de meeste openbare certificaten. De update van 15 juni 2026 van het Google Chrome Root Program Policy (versie 1.8) versterkt de vereisten voor Certificate Transparency en PKI-governance voor alle openbaar vertrouwde certificaattypen.

CA-eigenaren moeten elk TLS-serverauthenticatie-precertificaat registreren in ten minste één CT-logboek dat Chrome herkent als 'Bruikbaar' of 'Gekwalificeerd' voordat ze het certificaat uitgeven. Het exacte aantal vereiste SCT's varieert afhankelijk van de geldigheidsperiode van het certificaat. Chrome vereist twee SCT's voor certificaten die minder dan 180 dagen geldig zijn en drie voor certificaten die 180 dagen of langer geldig zijn. In beide gevallen blijft de onderliggende vereiste hetzelfde, namelijk onafhankelijke verificatie door meer dan één logboekbeheerder.

Chrome beoordeelt elk certificaat aan de hand van een vooraf gedefinieerde set logstatussen. Een logbestand kan zich in een van de vier relevante statussen bevinden voor naleving van de regelgeving.

• Gekwalificeerd: Onlangs geaccepteerd door Chrome, en de SCT's tellen al mee voor de CT-conformiteit.
• Bruikbaar: Volledig erkend en nieuwe inzendingen worden geaccepteerd, dus SCT's tellen mee, ongeacht of ze ingebed zijn of via de TLS-handshake worden geleverd.
• Alleen-lezen: Het accepteert geen nieuwe certificaten meer (de uiteindelijke omvang van de certificaatboom is gepubliceerd), maar blijft vertrouwd, dus bestaande SCT's tellen nog steeds mee.
• Uitgefaseerd: Wordt niet langer gebruikt voor nieuwe SCT's, en alleen ingebedde SCT's die vóór de uitfaseringsdatum zijn uitgegeven, tellen nog mee.

SCT's van logboeken die niet in een erkende goede staat verkeren, tellen niet mee voor de naleving. Certificaten die zijn ingediend voor logboeken die vervolgens niet meer aan de eisen voldoen, kunnen daarom hun CT-nalevingsstatus verliezen, zelfs na uitgifte. Chrome 148, uitgebracht op 5 mei 2026, heeft ook de ondersteuning voor SCT's die via gestapelde OCSP-reacties worden geleverd, verwijderd . Dit betekent dat SCT's nu in het certificaat zelf moeten zijn ingebed of via de TLS-handshake-extensie moeten worden geleverd. Elke implementatie die afhankelijk is van via OCSP gestapelde SCT's, moet opnieuw worden uitgegeven.

Certificaten die voorheen afhankelijk waren van verouderde uitzonderingen op de Certificate Transparency-regels of verouderde SCT-leveringsmechanismen, moeten worden herzien om ervoor te zorgen dat ze nog steeds voldoen aan het huidige CT-beleid van Chrome. De nieuwe regelgeving versterkt ook de noodzaak voor continue CT-monitoring, omdat elk onjuist uitgegeven certificaat nu in een openbaar logboek moet verschijnen. Hierdoor vormen deze logboeken een betrouwbaardere bron van dreigingsinformatie dan ooit tevoren.

Waarom het oudere RFC 6962-logboekontwerp problemen ondervond bij schaalvergroting

Het oorspronkelijke CT-logontwerp in RFC 6962 werkt als een klassieke, op een database gebaseerde API-service. Wanneer een CA een certificaat indient, slaat het logboek dit op in een database, werkt een Merkle-hashboom bij om de nieuwe vermelding cryptografisch vast te leggen en retourneert een SCT. Monitoren en auditors kunnen vervolgens via REST API-eindpunten het logboek raadplegen om vermeldingen op te halen en de consistentie te controleren.

Dit ontwerp werkte goed toen de hoeveelheid certificaten beheersbaar was. De Web PKI is dat punt echter allang voorbijgestreefd. Individuele CT-logs bevatten nu miljarden vermeldingen per temporele shard (een tijdssegment van een log dat alleen certificaten bevat die binnen een vast tijdsvenster verlopen), en de database achter elke log is een knelpunt geworden. Wanneer monitors grote hoeveelheden vermeldingen snel probeerden te lezen, raakten ze vaak overbelast. Logbeheerders reageerden met snelheidslimieten, wat de monitoring vertraagde en de waarde van CT als bijna realtime detectiemechanisme ondermijnde.

De garantie van een maximale samenvoegingsvertraging van 24 uur kwam ook herhaaldelijk in gevaar. Volgens RFC 6962 kan een logboek direct een SCT retourneren en heeft het vervolgens maximaal 24 uur de tijd om het certificaat daadwerkelijk in de Merkle-structuur op te nemen. Tijdens perioden met een hoge belasting dreigden logboeken die termijn te missen, waardoor situaties ontstonden waarin de SCT-belofte niet betrouwbaar kon worden nagekomen. Deze problemen maakten duidelijk dat de architectuur moest worden aangepast.

Hoe de Static CT API en Sunlight samenwerken

De Static CT API hanteert een fundamenteel andere aanpak. In plaats van query's uit een live database te beantwoorden, publiceert een Static CT-log alle gegevens als een hiërarchie van statische bestanden, zogenaamde tegels. Deze tegels worden aangeboden vanuit objectopslag zoals S3 of via een CDN. Er is geen server-side berekening nodig voor het leesproces, wat de bron is van de efficiëntievoordelen.

De Sunlight-implementatie, ontwikkeld door Filippo Valsorda in samenwerking met Let's Encrypt, is de meest gebruikte realisatie van deze specificatie. Omdat het leespad alleen statische bestanden bevat, kan het volledig via een CDN worden aangeboden. Monitoren halen daardoor cachebare tegels op in plaats van herhaaldelijk een live database te bevragen. Dit elimineert de bottleneck in het leespad die monitoring onder RFC 6962 belemmerde en vermindert de benodigde bandbreedte en rekenkracht voor een logoperator aanzienlijk.

Ook het schrijfproces is verbeterd. Sunlight bundelt inzendingen en integreert ze in de Merkle-structuur voordat een SCT wordt geretourneerd. Dit elimineert de maximale samenvoegingsvertraging volledig. Een SCT wordt pas uitgegeven nadat het certificaat in de structuur is opgenomen, waardoor de belofte van de SCT altijd al is ingelost.

Het logboek is opgebouwd uit tegels van elk 256 vermeldingen. Elke tegel is een statisch bestand dat wordt opgeslagen in objectopslag of op een lokaal bestandssysteem. Het logboek is tijdelijk geshard, waardoor elke shard alleen certificaten accepteert waarvan de NotAfter-datum binnen een specifiek tijdsvenster valt, meestal zes maanden. Dit beperkt de grootte van de shards en houdt de opslag beheersbaar.

Let's Encrypt heeft zijn RFC 6962-logs op 30 november 2025 omgezet naar alleen-lezen en ze op 28 februari 2026 volledig uitgeschakeld. Hun productie-CT-logs draaien nu op Sunlight, met Sycamore en Willow als de primaire productie-logs. Het TrustFabric-team van Google heeft TesseraCT uitgebracht, een implementatie van een statische CT API die een alternatief biedt voor de op Trillian gebaseerde CTFE die veel oudere logs aandrijft. Het ecosysteem is resoluut overgestapt op deze architectuur.

Hoe CT-monitoring tegenwoordig werkt

De manier waarop u gegevens verzamelt, hangt af van het type logboek. De twee onderstaande subsecties behandelen monitoring aan de hand van de oudere RFC 6962-logboeken en de nieuwere Static CT-logboeken.

Monitoring aan de hand van RFC 6962-logboeken

Met een RFC 6962-logboek roept een monitor het get-entries-eindpunt aan met een begin- en eindindex, haalt batches certificaten op en schuift zijn positie op naarmate er nieuwe vermeldingen binnenkomen. Het logboek haalt vermeldingen uit een database en retourneert bij elke vermelding de volledige certificaatketen, waardoor de toewijzing van een certificeringsinstantie (CA) eenvoudig is.

Monitoring aan de hand van statische CT-logboeken

Met een statisch CT-logbestand downloadt een monitor datategels rechtstreeks. Elke tegel bevat 256 items. De monitor haalt elke tegel op die hij nog niet heeft gezien, verwerkt de items en gebruikt het ondertekende checkpointbestand van het logbestand om de huidige boomgrootte bij te houden. Tegels zijn statisch en worden vanuit objectopslag aangeboden, waardoor monitors ze parallel kunnen ophalen zonder de snelheidslimieten te overschrijden.

Een praktisch verschil zit in de verwerking van de certificaatketen. RFC 6962-logboeken gaven per item een ​​volledige certificaatketen weer. Statische CT-logboeken voegen geen keten toe aan elk item. In plaats daarvan publiceert het logboek een bundel van een uitgever met de tussenliggende certificaten die deze heeft geaccepteerd. Monitoren die een volledige keten moeten reconstrueren voor CA-toewijzing, moeten deze samenstellen uit deze bundel. Dit maakt de monitor complexer, maar is een bewuste afweging om de gegevens per item compact te houden en de bandbreedte aanzienlijk te verminderen.

Vanuit het perspectief van een monitoringstrategie blijven de categorieën die de moeite waard zijn om te volgen consistent, ongeacht het type logboek.

• Nieuwe certificaten uitgegeven voor domeinen die u bezit, inclusief wildcard-matches.
• Certificaten van certificeringsinstanties die uw organisatie niet heeft geautoriseerd.
• Certificaten met een geldigheidsperiode die buiten uw polis valt.
• Certificaten tonen subdomeinen die u niet herkent.

Deze vier categorieën leveren de meeste concrete acties op.

Beschikbare hulpmiddelen voor CT-monitoring

Het monitoren van CT-logs is slechts de helft van het werk; de winst zit hem in het actie ondernemen op basis van de bevindingen. Dat is waar CertSecure Manager van Encryption Consulting van pas komt. Het is een platform dat CT-logmonitoring combineert met volledig certificaatlevenscyclusbeheer (CLM). Het scant continu CT-logs op certificaten die zijn uitgegeven voor uw domeinen en controleert elk certificaat aan de hand van uw inventaris van goedgekeurde certificaten. Zo kan uw team bevindingen onderzoeken en verhelpen vanuit één centrale console, in plaats van verschillende zoek- en waarschuwingssystemen te moeten gebruiken.

Certstream biedt een realtime WebSocket-feed van CT-logboekvermeldingen uit alle actieve logboeken. Beveiligingsteams gebruiken dit om filter- en waarschuwingssystemen op te zetten die teams waarschuwen zodra een overeenkomend certificaat in de Certificate Transparency-logboeken verschijnt.

Google houdt een actuele lijst bij van erkende CT-monitoringdiensten op certificate.transparency.dev. Voor teams die aangepaste monitors ontwikkelen, is de C2SP static-ct-api-specificatie de complete technische referentie voor tegelindeling en checkpointstructuur.

Welke tool uw team ook gebruikt, de output is een stroom certificaatgebeurtenissen die gesorteerd en beoordeeld moeten worden. Het ontwerp van waarschuwingen en de integratie met uw incidentresponsproces zijn net zo belangrijk als de verwerkingspipeline zelf. Deze tools verzorgen de verwerking; het correleren van gebeurtenissen met uw inventaris van geautoriseerde certificaten en het daarop reageren, is waar een CLM- platform van pas komt.

Dreigingspatronen die het waard zijn om in de gaten te houden

Ruwe CT-gegevens zijn op zichzelf niet bruikbaar. Effectieve monitoring vereist inzicht in welke patronen wijzen op een reëel probleem.

Ongeautoriseerde certificaatuitgifte : Er wordt een certificaat voor uw domein uitgegeven door een certificeringsinstantie (CA) waarmee u geen relatie hebt. Dit kan duiden op een omzeiling van de domeinvalidatie, een gecompromitteerde CA of een aanvaller met voldoende DNS-controle om de geautomatiseerde domeinvalidatie te omzeilen. Het snel detecteren hiervan was het oorspronkelijke doel waarvoor CT is ontworpen.

Schaduwcertificaten : certificaten die zijn uitgegeven voor infrastructuur die uw organisatie beheert, maar niet centraal. Ontwikkelteams die gebruikmaken van persoonlijke CA-accounts en certificaten die zijn uitgegeven voor onbeheerde, publiekelijk toegankelijke subdomeinen of infrastructuur buiten goedgekeurde PKI- processen zijn de meest voorkomende voorbeelden. Schaduwcertificaten creëren zowel een beveiligingslek als een risico op het gebied van compliance.

Blootstelling van subdomeinen : Elk subdomein in een certificaat is openbaar vindbaar zodra het certificaat is geregistreerd. Testomgevingen, interne tools en producten in de pre-lanceringsfase worden vindbaar zodra ze een certificaat ontvangen. Door uw eigen domeinen te monitoren met CT krijgt u inzicht in deze kwetsbaarheid voordat een aanvaller er toegang toe heeft.

Indicatoren voor onjuiste uitgifte : Certificaten met onverwachte Subject Alternative Names (SAN's), onverwachte uitgevers, ongebruikelijke Extended Key Usage (EKU)-waarden of afwijkende certificaatvelden kunnen wijzen op een fout in het CA-beleid of opzettelijke manipulatie. Geautomatiseerde veldanalyse op grote schaal maakt het mogelijk om deze betrouwbaar te signaleren.

Infrastructuur voor phishing en typosquatting : Aanvallers verkrijgen regelmatig certificaten voor domeinen die visueel lijken op de naam van een doelorganisatie. Het monitoren van CT op sterke overeenkomsten en veelvoorkomende substitutiepatronen geeft vroegtijdige waarschuwingen voor de opbouw van een phishinginfrastructuur.

Het herkennen van deze patronen in ruwe CT-data is één ding. Er snel op reageren, in alle domeinen die u beheert, is iets heel anders. Het overbruggen van die kloof is de taak van een CLM- platform, dat een stroom CT-waarschuwingen omzet in geprioriteerd werk dat uw team kan volgen en oplossen.

Hoe encryptieconsultancy kan helpen

Certificaattransparantiemonitoring is het meest waardevol wanneer deze is gekoppeld aan een CLM-platform dat actie kan ondernemen op basis van de informatie in de logboeken. Het zien van een ongeautoriseerd certificaat in een CT-logboek is alleen nuttig als uw team weet welke CA het heeft uitgegeven, of het via een goedgekeurd proces is aangevraagd en hoe snel het kan worden ingetrokken en vervangen. Zonder een CLM-platform dat deze context biedt, leiden CT-waarschuwingen tot ruis in plaats van actie.

CertSecure Manager van Encryption Consulting is een leveranciersneutraal CLM-platform dat is ontworpen om beveiligings- en PKI-teams volledig inzicht en controle te geven over hun certificaatomgeving. Het detecteert en inventariseert automatisch certificaten in cloud-, on-premises- en hybride omgevingen, zodat uw team altijd weet wat er is en waar. Wanneer een CT-waarschuwing wordt geactiveerd voor een certificaat dat al in de inventaris staat, kan deze automatisch worden gecorreleerd en bevestigd. Wanneer een waarschuwing wordt geactiveerd voor iets onbekends, toont CertSecure Manager dit direct als een onderzoeksitem met volledige context over de uitgever en de implementatie.

CertSecure Manager automatiseert niet alleen de ontdekking van certificaten, maar ook de volledige levenscyclus ervan, van inschrijving en uitgifte tot verlenging en intrekking. Het dwingt op beleid gebaseerde uitgifte af voor zowel openbare als private CA's, integreert met DevOps-workflows en -protocollen zoals ACME en SCEP, en biedt de auditregistratie die vereist is door compliance-frameworks zoals PCI DSS , ISO 27001 en NIST-richtlijnen. Voor organisaties die moeten voldoen aan de Chrome-vereiste van juni 2026, betekent dit dat u precies kunt vaststellen welke certificaten opnieuw moeten worden uitgegeven, deze via de juiste CA kunt routeren en de CT-conformiteit kunt bevestigen zonder handmatige controle.

Encryption Consulting biedt ook PKI-as-a-Service aan voor organisaties die een volledig beheerde private CA nodig hebben, evenals PQC-adviesdiensten . Dezelfde crypto-flexibiliteit die kortere certificaatlevensduren en CT-automatisering nu vereisen, is waar organisaties op zullen vertrouwen bij de overstap naar de post-kwantumstandaarden van NIST ( FIPS 203 , 204 en 205 , die in augustus 2024 worden afgerond). Naarmate de levensduur van certificaten steeds korter wordt en automatisering de norm wordt, is het beschikken over zowel de juiste tools als de expertise cruciaal om teams die de controle behouden te onderscheiden van teams die in paniek raken.

Conclusie

Certificate Transparency maakt van elk publiekelijk vertrouwd certificaat een openbaar register. Het controleren van dat register is een van de eenvoudigste manieren om certificaten te vinden die zonder uw toestemming voor uw domeinen zijn uitgegeven. Dit werkt echter alleen als iemand daadwerkelijk de logboeken in de gaten houdt en actie onderneemt op basis van de gevonden informatie.

In 2026 zijn er twee dingen veranderd. Chrome vereist nu dat bijna elk certificaat wordt gelogd, en de logs zelf zijn overgezet naar het snellere en goedkopere Static CT API-ontwerp. Samen maken ze CT-gegevens completer en gemakkelijker te verwerken, maar ze betekenen ook dat monitoring die is gebouwd voor het oude model een update nodig heeft. De teams die hier het meeste profijt van hebben, beschouwen CT-monitoring niet als een op zichzelf staande waarschuwingsfeed, maar als onderdeel van een breder CLM-platform dat kan onderzoeken wat het vindt en daarop kan reageren.