Je hoorde de term Certificate Transparency (CT) waarschijnlijk voor het eerst toen Google dit aankondigde als een vereiste voor alle Extended Validation (EV) SSL/TLS-certificaten uitgegeven na 1 januari 2015. Sindsdien heeft Google de vereiste uitgebreid naar alle types SSL-certificaten en kondigde het onlangs een deadline van april 2018 aan. Certificaten die na die datum worden uitgegeven en niet voldoen aan de vereisten van CT, worden niet vertrouwd in Chrome.
Bij GlobalSign hebben we achter de schermen hard gewerkt om al onze certificaten te voorzien van CT – Extended Validation (EV) sinds 2015, Domain Validated (DV) sinds augustus 2016 en Organization Validated (OV) sinds oktober 2017 – opdat onze klanten klaar zullen zijn voor de deadline van Google later dit jaar.
Voor iedereen die zich afvraagt wat CT nu precies inhoudt, geven we jullie hier alle nodige informatie.
Opmerking: Om de dingen niet nodeloos ingewikkeld te maken, gebruiken we de term SSL in plaats van TLS in dit artikel (met één uitzondering) omdat deze term meer gebruikt wordt. Meer informatie daarover kan je in dit gerelateerde artikel terugvinden.
Wat is Certificate Transparency?
Certificate Transparency is een open framework voor het controleren van SSL-certificaten. Domeineigenaars kunnen dit gebruiken om de uitgifte van certificaten voor hun domein te controleren en om foutief uitgegeven certificaten te detecteren. Vóór CT bestond er geen efficiënte manier om een uitgebreide lijst met certificaten uitgegeven voor jouw domein op te vragen.
Met CT worden alle certificaten openbaar gepubliceerd, wat meer inzicht en transparantie biedt in het ecosysteem van het Web PKI als geheel. Het Certificate Transparency Project heeft drie doelstellingen:
- Het een CA onmogelijk (of in elk geval heel moeilijk) maken om een SSL-certificaat te verlenen voor een domein zonder dat het certificaat zichtbaar is voor de eigenaar van dat domein.
- Een open controlesysteem bieden aan de hand waarvan elke domeineigenaar of CA kan nagaan of certificaten per vergissing of ten onrechte werden verleend.
- Gebruikers beschermen tegen certificaten die per vergissing of ten onrechte werden verleend.
Het Certificate Transparency-framework zorgt ervoor dat foutief uitgegeven certificaten snel en efficiënt kunnen worden gedetecteerd in vergelijking met het oude systeem, waar frauduleuze certificaten weken- of maandenlang schade konden aanrichten voordat ze ontdekt werden. Door verdachte certificaten tijdig te detecteren, kunnen CA's en domeineigenaars snel handelen en de certificaten intrekken.
Hoe Certificate Transparency werkt
De twee belangrijkste componenten van CT zijn de CT logs en Monitors.
CT logs bevatten gegevens van uitgegeven SSL-certificaten. Aan deze logs kan enkel informatie worden toegevoegd; er kunnen geen gegevens worden verwijderd of gewijzigd zodra een certificaat aan een log is toegevoegd. SSL-certificaten en precertificaten (meer info hieronder) kunnen worden gepubliceerd in CT logs. Bij ontvangst van een geldig SSL-certificaat of precertificaat stuurt de log een Signed Certificate Timestamp (SCT) terug als bewijs dat de log de aanvraag heeft ontvangen. CT logs gebruiken een cryptografisch mechanisme met de naam Merkle Tree Hash om te voorkomen dat loggegevens gewijzigd of verwijderd worden. Na publicatie zijn deze altijd zichtbaar voor het publiek. Browsers kunnen tijdens het verwerken van SSL-certificaten SCT's vereisen (als bewijs dat het certificaat openbaar werd gemaakt) bij het tot stand brengen van een TLS-sessie. Daardoor worden deze SCT's steeds belangrijker in het Web PKI. Later meer hierover.
Monitors voeren query's van CT logs uit en kunnen certificaten downloaden en opslaan om daarna rapporten te genereren. Monitors parseren de certificaten in subvelden en laten hun gebruikers query's voor certificaten aanmaken en uitvoeren. Voor domeineigenaars kan het interessant zijn om meldingen te ontvangen voor certificaten die werden uitgegeven voor hun domeinen, of voor certificaten die overeenkomen met hun organisatienaam, terwijl complianceteams kunnen streven naar conformiteit met de Baseline Requirements van het CA/Browser Forum of vereisten van het Root Program. Er zijn alleszins veel toepassingen voor Monitors. Een aantal externe services hebben tools voor CT Monitoring gelanceerd of hebben deze gebundeld in hun bestaande oplossingspakketten. Facebook lanceerde eind 2016 bijvoorbeeld een eigen gratis monitoringservice.
Wat zijn precertificaten?
Zoals hierboven vermeld, aanvaarden CT logs SSL-precertificaten en -certificaten. Een precertificaat bevat exact dezelfde gegevens als het 'echte' certificaat, maar bevat daarnaast een bijkomende extensie die het certificaat onbruikbaar maakt. Deze extensie wordt een 'poison extension' genoemd en wordt gebruikt om het certificaat te onderscheiden van het 'echte' certificaat. Omdat alle certificaten die worden uitgegeven door een CA unieke serienummers moeten bevatten, en omdat het precertificaat en het certificaat beide hetzelfde serienummer hebben, is het belangrijk om een van beide certificaten ongeldig of onbruikbaar te maken, vandaar de 'poison extension'.
Waarom zijn precertificaten nuttig?
Er bestaan meerdere methodes om SCT's te leveren aan browsers voor verwerking, maar de meest betrouwbare en handige methode is SCT's opnemen in het certificaat. Om SCT's te bekomen vóór de uitgifte (zodat deze kunnen worden opgenomen in het certificaat), moet de CA een precertificaat aanmaken, dit publiceren in CT logs, SCT's ontvangen en deze opnemen in het uiteindelijke certificaat.
Vóór de uitgifte van een certificaat kan een CA een precertificaat publiceren in CT logs met als doel het overeenkomstige certificaat uit te geven. Het aanmaken en publiceren van een precertificaat dat niet correct werd gevalideerd of geformatteerd, wordt in feite beschouwd als een foutieve uitgifte.
Wie kan certificaten verzenden naar CT logs?
Iedereen kan certificaten verzenden naar CT logs, maar alleen CA's kunnen precertificaten verzenden. Zoekmachines en operators van websites publiceren ook vaak certificaten in CT logs.
Sommige operators van CT logs aanvaarden certificaten enkel onder bepaalde roots, sommige aanvaarden geen verlopen certificaten en alle certificaten (of precertificaten) moeten bedoeld zijn voor gebruik als SSL-certificaten (d.w.z. u kunt geen S/MIME- of Code Signing-certificaten publiceren in CT logs).
SCT's gebruiken
De SCT – het bewijs dat het certificaat aan de log is toegevoegd – moet beschikbaar zijn voor de webbrowser opdat de browser het SSL-certificaat correct kan evalueren. Het precieze browsergedrag en de vereisten voor SCT's verschillen per browser, maar in alle gevallen moet de browser de SCT's ontvangen. Terwijl de browser in theorie SSL-certificaten kan publiceren in logs wanneer deze een TLS-sessie tot stand brengt om SCT's te bekomen, zou dit in de praktijk veel te duur zijn. SCT's kunnen op drie belangrijke manieren aan de browser worden geleverd:
1. Certificaatextensie
De meest gebruikte en meest betrouwbare methode om SCT's te leveren aan de browser, is dat de CA SCT's opneemt in het certificaat. Omdat de browser het SSL-certificaat nodig heeft om de TLS-sessie tot stand te brengen, is het certificaat zeker beschikbaar en kan het altijd worden gebruikt om SCT's te lezen.
Soms willen website-eigenaars de URL's van hun website nog niet bekendmaken voordat ze hun site lanceren en dus voorkomen dat hun certificaten vooraf worden gepubliceerd in CT logs. In dit geval wordt een van de andere methodes aanbevolen.
2. TLS (SSL)-extensie
De operator van de website kan SCT's leveren aan de browser binnen het TLS-protocol. In dit model verzendt de websiteoperator/webserver het certificaat naar CT logs en ontvangt de SCT's. De SCT's worden opgenomen in de TLS-handshake via een TLS-extensie met de naam 'signed_certificate_timestamp'. Het nadeel van deze leveringsmethode is dat operators van webservers de standaardconfiguraties van hun webservers moeten aanpassen en dat niet alle webservers deze optie ondersteunen.
3. OCSP Stapling
OCSP-berichten kunnen worden gebruikt om SCT's aan de browser te leveren. Voor deze methode zijn twee items vereist:
- De websiteoperator moet een webserver gebruiken die OCSP stapling ondersteunt en moet zijn server zo configureren dat deze een geldig OCSP-antwoord kan aanvragen en downloaden. Als dat niet gebeurt, is er geen garantie dat de browser het OCSP-bericht met de SCT's zal ophalen (veel browsers ondersteunen OCSP niet, dus dit is pas een betrouwbaar leveringsmechanisme als het OCSP-antwoord wordt opgenomen in het TLS-protocol).
- De CA moet zijn OSCP-service zo configureren dat deze SCT stapling ondersteunt. Nadat het certificaat is uitgegeven, zal de CA het publiceren in meerdere logs en SCT's ontvangen. Wanneer OCSP-antwoorden worden gegenereerd, zal de CA de SCT's bijvoegen aan het OSCP-bericht en zo beschikt de browser over zowel de intrekkingsstatus als de vereiste SCT's.
Hoewel methodes 2 en 3 beide een speciale serverconfiguratie vereisen, kunnen ze meer flexibiliteit bieden in vergelijking met methode 1 als CT logs niet vertrouwd worden omdat de websiteoperator en CA de gebruikte logs op een meer dynamische manier opnieuw kunnen configureren.
Het CT-beleid van Google
Om 'CT qualified' te zijn, eist Google dat een certificaat in meerdere logs voorkomt (minstens één log van Google en één niet van Google) en het aantal vereiste SCT's is afhankelijk van de geldigheidsperiode van het certificaat. Meer informatie vind je in het artikel Certificate Transparency in Chrome van Google.
Een lijst met logs kan je hier vinden.
Wat moet je doen om te voldoen aan de eisen van CT?
Eerst en vooral moet je de basisprincipes van CT kennen! De beste oplossing om ervoor te zorgen dat je conform bent, is een CA kiezen die SCT's toevoegt aan uitgegeven certificaten in overeenstemming met het CT-beleid van Google. Het merendeel van de SSL-certificaten van GlobalSign voldoet al aan het Google-beleid en binnen enkele maanden zullen alle certificaten hieraan voldoen, enkele maanden vóór Googles deadline van april 2018.
Tot nu toe is Google de enige browser die tijdlijnen voor CT heeft aangekondigd. Mozilla heeft een voorlopig beleid opgesteld, maar nog geen datums aangekondigd en we verwachten dat hun vereisten compatibel zullen zijn met de vereisten van Google. Je kan de discussie hier volgen. We werken dit artikel bij zodra er nieuwe informatie beschikbaar is.
Heb je vragen over Certificate Transparency en of jouw certificaten conform zijn? Neem contact met ons op. Wij helpen je graag verder.
