Certificate Transparency uitgelegd: wat CT-logs zijn en waarom ze ertoe doen

Certificate Transparency (CT) is een openbaar, manipulatiebestendig logsysteem dat elk publiek vertrouwd TLS-certificaat vastlegt zodra het wordt uitgegeven. Zo kan iedereen, jij ook, controleren of er zonder jouw medeweten een certificaat voor je domein is aangemaakt. Het houdt een malafide of gecompromitteerde certificaatautoriteit (CA) niet tegen bij het uitgeven van een fout certificaat, maar maakt die onterechte uitgifte vrijwel direct zichtbaar in plaats van dat die maandenlang verborgen blijft.

Als je de CT-logs voor je eigen domeinen nog nooit hebt bekeken, vertrouw je er volledig op dat je CA zich correct gedraagt en nooit wordt gehackt. CT geeft je een onafhankelijke manier om dat te verifiëren.

Wat is Certificate Transparency precies?

CT werd oorspronkelijk gedefinieerd in RFC 6962 (2013) en later als IETF-standaard vastgelegd in RFC 9162 (Certificate Transparency Version 2.0, 2021). Het kernidee: CA's dienen elk certificaat, of een "precertificaat"-versie ervan, vóór of bij de uitgifte in bij een of meer onafhankelijk beheerde CT-logs.

Elke log is een cryptografisch verifieerbare Merkle tree waaraan alleen kan worden toegevoegd. Een eenmaal toegevoegde vermelding kan niet worden bewerkt of stilletjes verwijderd zonder het wiskundige bewijs van de boom te breken, en iedereen die een monitor draait, kan die manipulatie opmerken. Daardoor zijn CT-logs betrouwbaar, ook al kan iedereen er iets bij indienen en zijn de beheerders van de logs zelf geen CA's.

Drie rollen laten het systeem werken:

• Logs: servers die inzendingen accepteren en een bewijs van opname teruggeven.
• Monitors: diensten (of scripts) die logs in de gaten houden op certificaten voor domeinen die voor hen relevant zijn.
• Auditors: clients (vaak ingebouwd in browsers) die controleren of de Merkle tree van een log intern consistent is en niet is gewijzigd.

Wat is een SCT en waarom is het belangrijk?

Wanneer een log een certificaat accepteert, geeft die een Signed Certificate Timestamp (SCT) terug: een cryptografische belofte dat het certificaat binnen een vastgestelde Maximum Merge Delay (MMD) in de log verschijnt, historisch zo'n 24 uur. De SCT kan op drie manieren worden geleverd: direct ingebed in het uiteindelijke certificaat, via een TLS-extensie tijdens de handshake, of via OCSP-stapling.

Moderne browsers vereisen een minimumaantal geldige SCT's van logs die door verschillende, onafhankelijke beheerders worden gedraaid, voordat ze een publiek uitgegeven certificaat vertrouwen. Chrome dwingt CT-naleving af voor alle publiek vertrouwde certificaten die sinds 30 april 2018 zijn uitgegeven: een certificaat zonder geldige SCT's wordt simpelweg niet vertrouwd, ongeacht wie het heeft ondertekend.

NoteCT vervangt de vertrouwensketen van certificaten niet, maar werkt ernaast. Wil je je kennis opfrissen over hoe die keten werkt, lees dan SSL-certificaten uitgelegd.

Waar CT-logs echt nuttig voor zijn

De praktische waarde voor iedereen die infrastructuur beheert, zit niet in de cryptografie maar in de zichtbaarheid. Met CT-logs kun je:

• Onbevoegde certificaten opsporen die voor je domein of subdomeinen zijn uitgegeven door een CA die je nooit hebt gebruikt.
• Schaduwsubdomeinen vinden: een CT-zoekopdracht onthult vaak vergeten staging-, test- of interne hostnamen waarvoor ongemerkt een publiek certificaat is uitgegeven.
• Het gedrag van CA's controleren nadat een inbreuk of onterechte uitgifte openbaar wordt, door de logs te doorzoeken op getroffen certificaten die aan je domeinen gekoppeld zijn.
• Misbruik van wildcards detecteren, waarbij een wildcardcertificaat voor je domein opduikt vanuit een bron die je niet herkent.

Dit is extra belangrijk voor organisaties met meerdere teams en voor bureaus die veel domeinen beheren bij verschillende registrars en clouds, waar een developer zomaar een certificaat kan aanvragen via een niet-goedgekeurde provider zonder dat iemand anders het merkt.

Hoe controleer je CT-logs?

Je hoeft geen eigen logmonitor te draaien om iets aan CT te hebben. Een paar praktische opties:

1. Doorzoek openbare CT-log-aggregators (crt.sh en vergelijkbare diensten) op je domein om elk certificaat te zien dat er ooit voor is gelogd.
2. Bekijk de SCT's van een live certificaat direct met onze SSL-checktool: die toont je de certificaatketen en geldigheid, zodat je kunt bevestigen wat er in productie daadwerkelijk wordt geserveerd.
3. Stel doorlopende monitoring in, zodat je een melding krijgt zodra er een nieuw certificaat voor je domein verschijnt, in plaats van af en toe handmatig te controleren.

Hier is een vereenvoudigd voorbeeld van hoe een zoekresultaat in een CT-log eruitziet voor een domein:

Die derde rij is precies waar je naar zoekt: een certificaat dat je niet hebt aangevraagd, van een CA die je niet herkent. Zie je dat voor een domein dat je beheert, trek het dan direct in, laat een nieuw certificaat uitgeven en onderzoek hoe de aanvrager door de domeinvalidatie heeft kunnen komen.

TipBeheer je certificaten bij meerdere providers, combineer CT-logcontroles dan met actieve monitoring van vervaldatums. Bekijk Certificaatbeheer om verlengingsdata en de gezondheid van certificaatketens vanuit één dashboard te volgen in plaats van per providerconsole.

Voorkomt CT onterecht uitgegeven certificaten?

Nee, en dit is het deel dat het vaakst verkeerd wordt begrepen. CT is detecterend, niet preventief. Een kwaadwillende of gecompromitteerde CA kan nog steeds een fout certificaat uitgeven; CT garandeert alleen dat die uitgifte openbaar zichtbaar wordt, meestal binnen ongeveer 24 uur (de MMD), in plaats van voor onbepaalde tijd verborgen te blijven. De echte preventielaag zijn CAA-records, die CA's vertellen welke van hen überhaupt certificaten voor je domein mogen uitgeven. Heb je die nog niet ingesteld, dan is dat een grotere en goedkopere winst dan alleen CT-monitoring. Zie de gids over DNS-recordtypes voor de CAA-syntax.

Samen gebruikt verkleint CAA de kans op onterechte uitgifte en vangt CT-logmonitoring op wat er toch doorheen glipt. Geen van beide is op zichzelf een volledig antwoord.

CT-logs vs. algemene SSL-monitoring

Het is goed om helder te hebben wat elke laag je precies vertelt:

Zoeken in CT-logs is terugkijkend en geldt voor het hele domein; live SSL-checks zijn momentopnames en gelden per host. Je wilt allebei. Voor de monitoringkant legt websitemonitoring uitgelegd uit hoe uptime- en SSL-vervalchecks op elkaar aansluiten.

Aan de slag met CT-toezicht

Beheer je meer dan een handvol domeinen, dan is eens per kwartaal handmatig zoeken op crt.sh niet genoeg: er worden continu certificaten uitgegeven, en een kwaadaardig certificaat kan maandenlang actief zijn voordat iemand het opmerkt. De realistische aanpak: weet welke CA's je daadwerkelijk gebruikt, let op alles wat buiten die lijst valt, en houd de vervaldatums en ketengezondheid van certificaten onder actieve monitoring in plaats van pas te controleren als er iets misgaat.

Voer nu meteen een snelle check uit op een domein met de gratis SSL-checktool, of breng het bijhouden van certificaten bij al je providers samen in het certificaatbeheer van InfraNest, zodat je niet op je geheugen hoeft te vertrouwen om op te merken wat CT-logs allang weten.