Wat TLS doet

Begin met `openssl s_client -connect pixzo.nl:443` en je ziet wat elke browser stilletjes doet: een certificaat controleren voordat er één byte over de lijn gaat. TLS regelt die controle, en dit artikel legt uit hoe certificaten, Certificate Authorities en de Nederlandse PKIoverheid daarin passen — voor wie een server beheert of certificaten uitgeeft.

Vereisten

• Een Linux-server met OpenSSL 3.x (`openssl version`)
• Toegang tot een domeinnaam waarop je een certificaat wilt testen
• Basiskennis van de commandoregel

Wat TLS doet

Transport Layer Security (TLS) versleutelt gegevens tussen twee systemen — een browser en een webserver, een mailclient en een mailserver, een API-client en een API-server. Zonder TLS leest iedereen op het netwerk mee. Met TLS niet, omdat het protocol twee soorten cryptografie combineert.

Tijdens de handshake wisselen client en server sleutels uit met asymmetrische cryptografie. Dat is veilig maar traag. Zodra de sleuteluitwisseling staat, schakelt de verbinding over op symmetrische cryptografie voor de eigenlijke gegevens. Sneller, en de sleutel is alleen bij de twee partijen bekend.

TLS is de opvolger van SSL, die als verouderd en onveilig geldt. De eerste TLS-versie, TLS 1.0, verscheen in januari 1999 als RFC 2246. Inmiddels zijn er TLS 1.1, 1.2 en 1.3 — elk met sterkere versleuteling en snellere handshakes. TLS 1.3 uit 2018 is de enige versie die je vandaag nog zou willen toestaan.

Waar certificaten in beeld komen

Asymmetrische cryptografie lost één probleem niet op: hoe weet je dat de publieke sleutel die je ontvangt echt van de server is en niet van iemand die het verkeer onderschept? Daarvoor zijn certificaten.

Een certificaat bevat een publieke sleutel, identiteitsinformatie over de eigenaar, en een digitale handtekening van een Certificate Authority (CA). Die CA is een vertrouwde derde partij die verklaart: "deze sleutel hoort bij dit domein".

Wanneer jouw browser verbinding maakt met een server, controleert hij drie dingen:

1. Is het certificaat ondertekend door een CA die de browser vertrouwt? 2. Is het certificaat nog geldig, dus niet verlopen of ingetrokken? 3. Komt de domeinnaam in het certificaat overeen met de server waarmee je verbinding maakt?

Klopt een van deze drie niet, dan toont de browser een waarschuwing — of weigert hij de verbinding helemaal.

De infrastructuur erachter: PKI

Certificaten bestaan niet los. Ze hangen in een Public Key Infrastructure (PKI): een geheel van regels en systemen voor het uitgeven, beheren, vernieuwen en intrekken van certificaten. Aan de top van die hiërarchie staan root certificates. Die zijn zelfondertekend en vormen het anker van vertrouwen. Onder de root hangen tussenliggende CAs die de dagelijkse certificaten uitgeven.

Root certificates hebben een lange geldigheidsduur — vaak vijftien tot twintig jaar. Dat is geen bureaucratie maar noodzaak: roots zitten ingebakken in besturingssystemen en browsers. Ze vervangen is een operatie die jaren kost, omdat elk apparaat ter wereld de nieuwe root moet leren vertrouwen.

OpenSSL kan een certificaat inspecteren. Voor een domein:

openssl s_client -connect pixzo.nl:443 -showcerts

Dit toont de volledige certificaatketen: het servercertificaat, eventuele tussenliggende CAs, en de root. Met `-servername pixzo.nl` dwing je SNI af als de server meerdere domeinen host.

PKIoverheid: de Nederlandse overheidscertificaten

De Nederlandse overheid heeft een eigen PKI-omgeving: PKIoverheid, beheerd door Logius, een agentschap van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties. Deze infrastructuur levert certificaten voor digitale dienstverlening — van overheidswebsites tot beveiligde e-mail en elektronische handtekeningen.

PKIoverheid kent drie stamcertificaten, volgens een NCSC-factsheet:

• Staat der Nederlanden EV Root CA
• Staat der Nederlanden Root CA G3
• Staat der Nederlanden Private Root CA G1

De G3- en G1-roots zijn geldig van 14 november 2013 tot 13 november 2028. Daarnaast bestaat een TRIAL PKIoverheid Root CA G3, geldig van 12 juli 2019 tot 14 november 2028.

Die lange levensduur is gebruikelijk voor roots, maar het betekent ook dat een gecompromitteerde root jarenlang schade kan aanrichten. Daarom controleert Logius de uitgifte onder de tussenliggende CAs streng.

Wat er misging en waarom het veranderde

PKIoverheid heeft incidenten gekend. Logius meldde op 2 augustus 2021 dat in 2019 en 2020 problemen waren geweest met publiek vertrouwde webservercertificaten voor overheidswebsites. De certificaten waren uitgegeven onder een oudere PKI-structuur die niet voldeed aan de eisen van moderne browsers.

De reactie was een nieuw PKI-domein: Server CA 2020, ingevoerd in de zomer van 2020. Alle publiek vertrouwde webservercertificaten voor overheidswebsites vielen daaronder, tot het domein afliep op 6 december 2022.

De bredere consequentie kwam daarna. Sinds 2022 gebruikt de overheid PKIoverheid-certificaten niet meer voor publiek toegankelijke websites. Daar liggen nu commercieel verkregen certificaten van internationaal vertrouwde CAs — denk aan Let's Encrypt, DigiCert of Sectigo. De reden is compatibiliteit: commerciële CAs zitten in de vertrouwde wortels van vrijwel elk apparaat, en hun uitgifteprocessen volgen internationale standaarden die browsers eisen.

Dat betekent niet dat PKIoverheid verdwijnt. Voor interne en gespecialiseerde toepassingen — zoals beveiligde e-mail binnen de overheid of elektronische handtekeningen — blijft de infrastructuur actief. En ze vernieuwt: in juli 2026 lanceerde Logius de nieuwe generatie G4-certificaten, naast G3+.

Organisaties die PKIoverheid gebruiken, moeten vóór november 2028 overstappen van G3(+) en G1 Private-certificaten naar G4. De officiële end-of-life-datum voor G1 en G3 is 12 november 2028, volgens de FAQ van PKI Partners.

Kortere levensduur, meer werk

Een andere verschuiving raakt iedereen die certificaten beheert: de geldigheidsduur van publieke certificaten daalt. Vanaf 15 maart 2026 tot 15 maart 2029 wordt de maximale levensduur stapsgewijs verkort van 398 dagen naar 47 dagen.

De reden is beveiliging. Een gecompromitteerd certificaat is minder waard als het binnen enkele weken verloopt. En een certificaat dat elke anderhalve maand vernieuwd moet worden, dwingt organisaties om certificaatbeheer te automatiseren — handmatig vernieuwen is bij 47 dagen geen optie meer.

Dit raakt ook de keuze voor een CA. Een commercieel certificaat van 398 dagen kost meer dan een van 90 dagen via Let's Encrypt, maar bij 47 dagen maakt dat verschil minder uit: je moet toch automatiseren. Let's Encrypt gebruikt de ACME-protocol voor automatische vernieuwing; commerciële CAs bieden dat inmiddels ook. Wie nu nog handmatig certificaten verlengt, heeft over twee jaar een probleem.

Certificaten zelf maken en controleren

Certificaten volgen de X.509-standaard, versie 3 (X.509v3) is de meest gebruikte. Met OpenSSL maak je een eigen certificaat:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=pixzo.nl"

Dit genereert een private key en een Certificate Signing Request (CSR). De CSR stuur je naar een CA die er een certificaat van maakt. Voor een zelfondertekend certificaat — geschikt voor testen, niet voor productie — gebruik je:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key -out server.crt -days 90 \
  -subj "/CN=pixzo.nl" \
  -addext "subjectAltName=DNS:pixzo.nl,DNS:www.pixzo.nl"

De `-addext` regel is geen detail: moderne browsers negeren het CN-veld en kijken alleen naar Subject Alternative Name (SAN). Zonder SAN weigert Chrome de verbinding.

Voor productiecertificaten stel je extensies in via een configuratiebestand, zoals beschreven in de handleiding `x509v3_config`. Daarin definieer je SAN, Key Usage en Extended Key Usage — velden die bepalen waarvoor een certificaat mag worden gebruikt. Een certificaat voor serverauthenticatie heeft andere Extended Key Usage dan een certificaat voor codeondertekening; door elkaar halen levert fouten op bij validatie.

Controleren of een certificaat nog geldig is

Een certificaat kan verlopen voordat de datum aanbreekt — als de private key uitlekt, moet de CA het intrekken. Clients controleren dat via het Online Certificate Status Protocol (OCSP). In plaats van een volledige Certificate Revocation List (CRL) te downloaden, vraagt de client aan de OCSP-server van de CA: "is dit certificaat nog geldig?"

OpenSSL kan die check uitvoeren:

openssl ocsp -issuer issuer.crt -cert server.crt \
  -url http://ocsp.example.com -resp_text

Het antwoord bevat de status: `good`, `revoked` of `unknown`. In de praktijk doen browsers dit automatisch, maar bij het debuggen van verbindingsproblemen is het nuttig om handmatig te kunnen controleren of een certificaat is ingetrokken.

Veelgestelde problemen

Chrome meldt NET::ERR_CERT_COMMON_NAME_INVALID, maar het CN klopt. Chrome negeert het CN-veld sinds versie 58 en kijkt alleen naar SAN. Voeg `subjectAltName` toe aan het certificaat of de CSR, zoals in het voorbeeld hierboven.

De keten is incompleet: clients klagen over een onbekende uitgever. Servers moeten niet alleen het servercertificaat sturen, maar ook de tussenliggende CAs. Alleen de root hoef je niet mee te sturen — die heeft de client al. Combineer de certificaten in de juiste volgorde:

cat server.crt intermediate.crt > fullchain.pem

Certificaatvernieuwing lukt niet meer omdat de levensduur is verkort. Automatiseer vernieuwing met ACME (Let's Encrypt) of de equivalente tool van je commerciële CA. Bij 47 dagen maximale geldigheid is handmatig verlengen geen beheer maar een fulltime baan.

De verschuiving naar kortere certificaatlevensduren en de overgang naar G4 bij PKIoverheid wijzen allebei dezelfde kant op: certificaatbeheer wordt een geautomatiseerd proces, geen jaarlijkse handeling. Wie dat nu inricht, heeft straks minder werk — en wie het uitstelt, krijgt in november 2028 vanzelf de rekening.