Certificate Transparency-logs: wat ze over uw domeinen prijsgeven

Certificate Transparency (CT) is een systeem van logs waarin TLS-certificaten worden vastgelegd zodra certificaatautoriteiten ze uitgeven. Er kan alleen aan worden toegevoegd en iedereen kan ze lezen. Voor uw bedrijf betekent dat 2 dingen: de logs tonen aan iedereen voor welke hostnamen u certificaten hebt, en u ziet er ook in wanneer iemand een certificaat voor uw domein heeft gekregen waar niemand aan uw kant om heeft gevraagd.

Het protocol werd voor het eerst beschreven in RFC 6962 (juni 2013) en als versie 2.0 bijgewerkt in RFC 9162 (december 2021). Beide zijn Experimental RFC's, maar browsers steunen in de praktijk op CT: Chrome eist dat algemeen vertrouwde TLS-certificaten aan CT voldoen, en Apple heeft een eigen CT-beleid voor zijn platforms.

Vertrouwt een browser dus een certificaat voor yourcompany.com, dan bestaat er vrijwel zeker een logvermelding voor.

Wat de logs over uw bedrijf prijsgeven

Een CT-vermelding bevat de namen die het certificaat dekt, de uitgevende autoriteit en de geldigheidsdata. Samen tonen de vermeldingen voor uw domein:

• Uw subdomeinen. vpn.yourcompany.com, jira.yourcompany.com, staging-api.yourcompany.com: elke naam die ooit een eigen certificaat had.
• Uw leveranciers. Uitgevers en naamgevingspatronen verraden vaak welke hosting-, mail- of SaaS-platforms u gebruikt.
• Uw geschiedenis. Oude vermeldingen blijven in de log staan, dus namen van projecten die jaren geleden zijn stopgezet, blijven zichtbaar.
• Nieuwe certificaten zodra ze verschijnen. Een nieuwe vermelding voor een naam die u niet herkent, of van een autoriteit die u niet gebruikt, is reden om navraag te doen.

Niets hiervan is een fout in CT. Het doel van het systeem is juist dat onterecht uitgegeven certificaten niet verborgen kunnen blijven. Het gevolg is dat uw lijst met hostnamen niet privé is, dus u leest hem beter zelf voordat iemand anders dat doet.

Zo zoekt u zelf in de logs

De eenvoudigste manier is crt.sh, een zoekinterface voor CT-logs. Typ uw domein, of gebruik % als jokerteken om elk subdomein mee te nemen:

https://crt.sh/?q=%25.yourcompany.com

Voor een lijst die u kunt verwerken, voegt u &output=json toe:

curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
  | jq -r '.[].name_value' | sort -u

Let bij het lezen van de resultaten op:

• Namen die niemand herkent. Elke naam hoort bij een systeem met een bekende eigenaar.
• Test- en stagingnamen zoals dev, test, old, beta. Die wijzen vaak naar vergeten stagingservers.
• Namen die niet meer naar een adres verwijzen of die wijzen naar een platform dat u hebt verlaten. Controleer ze op verweesde DNS-records en subdomain takeover.
• Onverwachte uitgevers. Een certificaat van een autoriteit die u nooit hebt gebruikt, verdient een controle met het team dat uw DNS en hosting beheert.
• Recente data die u niet kunt verklaren. Een vers certificaat voor uw belangrijkste inloghostnaam waar niemand om heeft gevraagd, is het dringendste geval.

Houd er rekening mee dat wildcardcertificaten (*.yourcompany.com) geen afzonderlijke subdomeinen vermelden. De logs tonen u dus veel, maar niet alles.

Beperk wie mag uitgeven: het CAA-record

Met een CAA-record, gedefinieerd in RFC 8659, vertelt u certificaatautoriteiten welke van hen voor uw domein mogen uitgeven. Autoriteiten controleren het vóór de uitgifte. Een typische opzet:

yourcompany.com.  CAA 0 issue "letsencrypt.org"
yourcompany.com.  CAA 0 issuewild ";"
yourcompany.com.  CAA 0 iodef "mailto:security@yourcompany.com"

Dit staat één autoriteit toe, verbiedt wildcardcertificaten en geeft een adres voor meldingen. CAA vervangt CT niet: het beperkt wat kan worden uitgegeven, terwijl CT u toont wat werkelijk is uitgegeven.

Kortere certificaten, drukkere logs

Volgens CA/Browser Forum ballot SC-081, nu onderdeel van de Baseline Requirements, is de maximale geldigheid van algemeen vertrouwde TLS-certificaten 200 dagen voor certificaten uitgegeven vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027, en vanaf 15 maart 2029 nog maar 47. Vernieuwingen komen vaker en grotendeels geautomatiseerd, dus uw domeinen zullen meer CT-vermeldingen opleveren. Handmatig lezen wordt daardoor minder praktisch en een duidelijke referentielijst van "verwachte" certificaten des te nuttiger. Over de vernieuwing zelf leest u meer in waarom verlopen certificaten nog steeds websites platleggen.

Wat u doet als u iets onverwachts vindt

1. Zoek de eigenaar. Vraag IT, marketing en uw bureaus of zij het certificaat hebben aangevraagd.
2. Heeft niemand dat gedaan, neem dan contact op met de uitgevende autoriteit. Elke autoriteit heeft een manier om onterecht uitgegeven certificaten te melden en intrekking aan te vragen.
3. Controleer uw DNS en registrar. Een onverwacht certificaat kan volgen op een DNS-wijziging, dus loop de punten na uit ons artikel over wijzigingen van nameserver en registrar.
4. Voeg CAA toe of maak het strenger, zodat dezelfde autoriteit niet opnieuw kan uitgeven zonder uw toestemming.

Korte checklist

• Zoek op crt.sh naar %.yourcompany.com en bewaar de lijst met namen.
• Koppel elke naam aan een systeem en een eigenaar.
• Verwijder of herstel namen die nergens naartoe wijzen.
• Publiceer een CAA-record met de autoriteiten die u gebruikt.
• Bekijk nieuwe vermeldingen regelmatig, niet één keer per jaar.

De rol van Datahorses

Datahorses bewaakt uw bedrijf elke dag van buitenaf, en Certificate Transparency is een van de dingen die we voor u lezen: nieuwe certificaten voor uw domeinen, nieuwe subdomeinen en de CAA-records die ze moeten beperken. We gaan uw systemen niet binnen en hebben geen toegang nodig. Ziet iets er verkeerd uit, dan krijgt u de bevinding met duidelijke stappen, zoals beschreven in wat er gebeurt als we iets vinden. De volledige lijst van wat wij bewaken staat op de homepage.