What TLS does

Start with `openssl s_client -connect pixzo.nl:443` and you will see what every browser silently does: verify a certificate before a single byte goes over the wire. TLS handles that verification, and this article explains how certificates, Certificate Authorities, and the Dutch PKIoverheid fit into it — for anyone who manages a server or issues certificates.

Requirements

• A Linux server with OpenSSL 3.x (`openssl version`)
• Access to a domain name on which you want to test a certificate
• Basic knowledge of the command line

What TLS does

Transport Layer Security (TLS) encrypts data between two systems — a browser and a web server, a mail client and a mail server, an API client and an API server. Without TLS, anyone on the network can read along. With TLS they cannot, because the protocol combines two types of cryptography.

During the handshake, the client and server exchange keys using asymmetric cryptography. That is secure but slow. Once the key exchange is established, the connection switches to symmetric cryptography for the actual data. Faster, and the key is known only to the two parties.

TLS is the successor to SSL, which is considered outdated and insecure. The first TLS version, TLS 1.0, appeared in January 1999 as RFC 2246. Since then, TLS 1.1, 1.2, and 1.3 have been released — each with stronger encryption and faster handshakes. TLS 1.3 from 2018 is the only version you would still want to allow today.

Where certificates come into play

Asymmetric cryptography does not solve one problem: how do you know that the public key you receive really belongs to the server and not to someone intercepting the traffic? That is what certificates are for.

A certificate contains a public key, identity information about the owner, and a digital signature from a Certificate Authority (CA). That CA is a trusted third party that declares: "this key belongs to this domain".

When your browser connects to a server, it checks three things:

1. Is the certificate signed by a CA that the browser trusts? 2. Is the certificate still valid, meaning not expired or revoked? 3. Does the domain name in the certificate match the server you are connecting to?

If any of these three is incorrect, the browser shows a warning — or refuses the connection entirely.

The infrastructure behind it: PKI

Certificates do not exist in isolation. They are part of a Public Key Infrastructure (PKI): a set of rules and systems for issuing, managing, renewing, and revoking certificates. At the top of that hierarchy are root certificates. These are self-signed and form the anchor of trust. Below the root are intermediate CAs that issue the day-to-day certificates.

Root certificates have a long validity period — often fifteen to twenty years. That is not bureaucracy but necessity: roots are embedded in operating systems and browsers. Replacing them is an operation that takes years, because every device in the world must learn to trust the new root.

OpenSSL can inspect a certificate. For a domain:

openssl s_client -connect pixzo.nl:443 -showcerts

This shows the full certificate chain: the server certificate, any intermediate CAs, and the root. With `-servername pixzo.nl` you force SNI if the server hosts multiple domains.

PKIoverheid: the Dutch government certificates

The Dutch government has its own PKI environment: PKIoverheid, managed by Logius, an agency of the Ministry of the Interior and Kingdom Relations. This infrastructure provides certificates for digital services — from government websites to secure email and electronic signatures.

PKIoverheid has three root certificates, according to an NCSC fact sheet:

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

The G3 and G1 roots are valid from 14 November 2013 to 13 November 2028. In addition, there is a TRIAL PKIoverheid Root CA G3, valid from 12 July 2019 to 14 November 2028.

That long lifespan is common for roots, but it also means that a compromised root can cause damage for years. Therefore, Logius strictly monitors issuance under the intermediate CAs.

What went wrong and why it changed

PKIoverheid has seen incidents. Logius reported on 2 August 2021 that in 2019 and 2020 there had been problems with publicly trusted web server certificates for government websites. The certificates were issued under an older PKI structure that did not meet the requirements of modern browsers.

The response was a new PKI domain: Server CA 2020, introduced in the summer of 2020. All publicly trusted web server certificates for government websites fell under it, until the domain expired on 6 December 2022.

The broader consequence came afterward. Since 2022, the government no longer uses PKIoverheid certificates for publicly accessible websites. These now use commercially obtained certificates from internationally trusted CAs — think Let's Encrypt, DigiCert, or Sectigo. The reason is compatibility: commercial CAs are in the trusted roots of almost every device, and their issuance processes follow international standards that browsers require.

That does not mean PKIoverheid is disappearing. For internal and specialized applications — such as secure email within the government or electronic signatures — the infrastructure remains active. And it is being renewed: in July 2026, Logius launched the new generation of G4 certificates, alongside G3+.

Organizations using PKIoverheid must switch from G3(+) and G1 Private certificates to G4 before November 2028. The official end-of-life date for G1 and G3 is November 12, 2028, according to the PKI Partners FAQ.

Shorter lifespan, more work

Another shift affects everyone who manages certificates: the validity period of public certificates is decreasing. From March 15, 2026, to March 15, 2029, the maximum lifespan will be gradually reduced from 398 days to 47 days.

The reason is security. A compromised certificate is worth less if it expires within a few weeks. And a certificate that must be renewed every six weeks forces organizations to automate certificate management — manual renewal is no longer an option at 47 days.

This also affects the choice of a CA. A commercial certificate of 398 days costs more than one of 90 days via Let's Encrypt, but at 47 days that difference matters less: you have to automate anyway. Let's Encrypt uses the ACME protocol for automatic renewal; commercial CAs now offer that as well. Anyone still renewing certificates manually today will have a problem in two years.

Creating and checking certificates yourself

Certificates follow the X.509 standard; version 3 (X.509v3) is the most widely used. With OpenSSL you create your own certificate:

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

This generates a private key and a Certificate Signing Request (CSR). You send the CSR to a CA, which turns it into a certificate. For a self-signed certificate — suitable for testing, not for production — you use:

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"

The `-addext` line is not a detail: modern browsers ignore the CN field and look only at the Subject Alternative Name (SAN). Without a SAN, Chrome refuses the connection.

For production certificates, you set extensions via a configuration file, as described in the `x509v3_config` manual. There you define SAN, Key Usage, and Extended Key Usage — fields that determine what a certificate may be used for. A certificate for server authentication has different Extended Key Usage than one for code signing; mixing them up causes validation errors.

Checking whether a certificate is still valid

A certificate can expire before its date arrives — if the private key leaks, the CA must revoke it. Clients check this via the Online Certificate Status Protocol (OCSP). Instead of downloading a full Certificate Revocation List (CRL), the client asks the CA's OCSP server: "is this certificate still valid?"

OpenSSL can perform that check:

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

The response contains the status: `good`, `revoked`, or `unknown`. In practice, browsers do this automatically, but when debugging connection issues, it is useful to be able to manually check whether a certificate has been revoked.

Common problems

Chrome reports NET::ERR_CERT_COMMON_NAME_INVALID, but the CN is correct. Chrome has ignored the CN field since version 58 and looks only at the SAN. Add `subjectAltName` to the certificate or CSR, as in the example above.

The chain is incomplete: clients complain about an unknown issuer. Servers must send not only the server certificate but also the intermediate CAs. Only the root does not need to be sent — the client already has it. Combine the certificates in the correct order:

cat server.crt intermediate.crt > fullchain.pem

Certificate renewal no longer works because the lifespan has been shortened. Automate renewal with ACME (Let's Encrypt) or the equivalent tool from your commercial CA. At 47 days of maximum validity, manual renewal is not management but a full-time job.

The shift toward shorter certificate lifespans and the transition to G4 at PKIoverheid both point in the same direction: certificate management becomes an automated process, not an annual task. Those who set it up now will have less work later — and those who postpone it will get the bill in November 2028.