WordPress SSL-certificaat: wat het is en hoe je er een installeert

Een SSL-certificaat is wat van http://jouwsite.nl een https://jouwsite.nl maakt, mét het slotje in de adresbalk. De onderliggende techniek heet eigenlijk TLS (de opvolger van SSL), maar de hele sector blijft "SSL-certificaat" zeggen en dit artikel dus ook. Wat het certificaat doet, zijn twee dingen tegelijk: het versleutelt elke byte tussen de browser van de bezoeker en je webserver, én het bewijst aan de browser dat de server waarmee hij praat ook écht de domeinnaam beheert die je intikte. WordPress geeft het certificaat niet uit. Je webserver of je hostingprovider doet dat, en WordPress volgt gewoon wat de server en de database hem vertellen over welke URL gebruikt moet worden.

Dit is een concept-artikel. Zoek je de precieze commando's om WordPress na installatie richting HTTPS te dwingen, dan moet je bij HTTPS afdwingen in WordPress zijn. Staat je certificaat goed maar laat je site nog steeds een kapot slotje zien, dan is dat mixed content in WordPress. Wil je het grotere beveiligingsverhaal, begin dan bij WordPress beveiliging verharden.

Wat een SSL-certificaat écht doet

RFC 8446, de specificatie van TLS 1.3, beschrijft drie eigenschappen die het protocol levert: authenticatie, vertrouwelijkheid en integriteit. Authenticatie betekent dat de server zijn identiteit kan bewijzen aan de client. Vertrouwelijkheid betekent dat alleen de twee eindpunten kunnen lezen wat ze tegen elkaar zeggen. Integriteit betekent dat geen van beide een bericht onderweg kan wijzigen zonder dat de ander het merkt. Het certificaat is hoe die authenticatie gebeurt, en de rest volgt daaruit.

Denk aan het certificaat als een paspoort. Je webserver bezit een private key die alleen hij kent. Een vertrouwde derde partij, de certificaatuitgever (de CA), heeft een document ondertekend dat zegt: "de entiteit met deze private key beheert het domein jouwsite.nl". Als een browser contact maakt met je site, laat de server dat ondertekende document zien en bewijst dat hij ook daadwerkelijk de bijbehorende private key bezit. De browser controleert de handtekening van de CA tegen zijn ingebouwde lijst met vertrouwde uitgevers, en als alles klopt vertrouwt hij erop dat hij écht met de server voor jouwsite.nl praat en niet met een aanvaller op dezelfde koffiewinkel-wifi. Daarna onderhandelen beide kanten een verse symmetrische sleutel, en de rest van het gesprek is gewoon versleuteld.

De versleuteling zelf is commodity. GlobalSign, een betaalde CA, zegt het zelf bot: gratis en betaalde certificaten bieden allebei "256-bit certificate encryption and 2048-bit key encryption". De cipher suite wordt aan het begin van de verbinding onderhandeld tussen browser en server, en die onderhandeling trekt zich niets aan van wat het certificaat heeft gekost. De verschillen tussen certificaattypes gaan over identiteit, niet over cryptografie. Dat is veruit het belangrijkste wat je over dit onderwerp moet onthouden.

DV, OV en EV: de drie identiteitsniveaus

SSL.com legt het zo uit: "all X.509 certificates use similar methods to assure encryption, authentication, and integrity" maar ze "vary significantly in the information they include about the identities that they secure". Er zijn drie niveaus, en het verschil zit in hoe grondig de CA controleert voordat hij ondertekent.

Domain Validation (DV). De CA bevestigt alleen dat degene die het certificaat aanvraagt het domein beheert. Die check is geautomatiseerd: de CA vraagt je een specifieke string in een DNS-record of in een bestand onder http://jouwsite.nl/.well-known/acme-challenge/... te zetten, wacht een paar seconden en ondertekent. Let's Encrypt is DV. De meeste hostingpanelen geven DV uit. Een DV-certificaat zegt: "iemand met DNS- of webroot-toegang tot dit domein heeft dit certificaat aangevraagd". Het zegt niet wie die iemand is.

Organization Validation (OV). De CA verifieert dat er een juridische entiteit bestaat en dat die het domein beheert. Daar komen documenten, een telefoontje en een paar werkdagen bij kijken. De organisatienaam belandt in het certificaat zelf en is zichtbaar als je op het slotje klikt en de certificaatdetails opent. Browsers tonen die naam niet meer prominent, en dat is de belangrijkste reden dat OV marktaandeel heeft verloren.

Extended Validation (EV). De CA voert een diepere juridische en operationele controle uit en ondertekent dan pas. Vroeger zorgden EV-certificaten voor een groene adresbalk met de bedrijfsnaam naast de URL. Die UI is weg. Zowel Chrome als Firefox hebben de EV-indicator tussen 2019 en 2020 uit de adresbalk gehaald nadat onderzoek liet zien dat gebruikers hem niet lazen. Een EV-certificaat kost vandaag de dag nog steeds fors meer en vereist nog steeds een zwaarder verificatieproces, maar het zichtbare voordeel voor de bezoeker is vrijwel nul.

Voor een WordPress-site is DV gewoon de juiste standaard. Elke grote browser vertrouwt Let's Encrypt, Cloudflare, ZeroSSL en de andere gratis DV-uitgevers out of the box, en niets aan "dit is DV" is zichtbaar voor bezoekers. De gevallen waarin OV of EV wél te rechtvaardigen zijn, zijn smal: een gereguleerde zakelijke context waarin compliance-reviewers willen dat de organisatie in het certificaat wordt vastgelegd, of een brand-protection-scenario waarin geautomatiseerde scanners de EV-identiteit controleren. Een blog, een portfoliosite, een kleine webshop of een SaaS-landingspagina horen gewoon op DV.

Let's Encrypt, de levensduur van 90 dagen en het traject dat je moet kennen

Let's Encrypt is de gratis, geautomatiseerde certificaatuitgever die HTTPS tot de standaard van het web heeft gemaakt. Op dit moment geeft Let's Encrypt zijn standaardcertificaten uit met 90 dagen geldigheid. De Let's Encrypt FAQ is daar expliciet over: "Our default certificates are valid for 90 days" en "there is no way to adjust these lifetimes". Ze raden aan om elke 60 dagen te vernieuwen, zodat je marge hebt.

Die 90 dagen zijn niet willekeurig. Let's Encrypt legt de logica uit in twee zinnen die het lezen waard zijn. Kortlopende certificaten "limit damage from key compromise and mis-issuance" omdat een gestolen sleutel of een per ongeluk uitgegeven certificaat sowieso binnen een kwartaal verloopt, én ze "encourage automation, which is absolutely essential for ease-of-use". Langlopende certificaten maken het mogelijk om de vernieuwing in een agenda voor volgend jaar te zetten en er niet meer aan te denken tot er iets misgaat. Kortlopende certificaten dwingen automatisering af, en dat is het enige model dat opschaalt naar het hele web.

Belangrijk: 90 dagen is de waarde van vandaag, geen constante. In april 2025 heeft het CA/Browser Forum ballot SC081v3 aangenomen, die een gefaseerde verlaging van de maximale TLS-certificaatgeldigheid voor elke publiek vertrouwde CA verplicht stelt, van de huidige limiet naar 47 dagen in 2029. Let's Encrypt heeft een eigen schema gepubliceerd dat standaardcertificaten tegen 2028 naar 45 dagen brengt: het tlsserver-ACME-profiel schakelt op 13 mei 2026 over op 45-daagse uitgifte, het standaard classic-profiel zakt op 10 februari 2027 naar 64 dagen, en het classic-profiel gaat op 16 februari 2028 naar 45 dagen. Als je dit artikel na februari 2027 leest, is het "90 dagen"-getal hierboven al verouderd, en de praktische implicatie is maar één ding: vernieuwen moet automatisch gebeuren, want geen enkel mens zou certificaten elke paar weken met de hand moeten vernieuwen.

Er is trouwens ook nog een kortlopende optie. Sinds januari 2026 is het zesdaagse certificaatprofiel van Let's Encrypt algemeen beschikbaar; het geeft certificaten uit met een geldigheid van 160 uur. Dat is opt-in, het vereist een ACME-client die het shortlived-profiel ondersteunt, en het is bedoeld voor automatiseringszware setups, niet voor een doorsnee WordPress-site. Goed om te weten dat het bestaat, en dan weer verder.

Hoe het certificaat écht op een WordPress-site terechtkomt

Er zijn drie praktische routes, en welke voor jou geldt hangt meestal af van het type hosting waarop je zit. Elke route eindigt met hetzelfde: een certificaat en een private key geïnstalleerd op je webserver, en WordPress zelf zo geconfigureerd dat het https://-URL's gebruikt.

Route 1: managed WordPress-hosting. Je host beheert het certificaat. Een knopje in het hostingpaneel, of helemaal niets, zet het aan en vernieuwen gebeurt stilletjes op de achtergrond. Dit is de normale flow bij Kinsta, WP Engine, SiteGround, Cloudways, de meeste cPanel-hosts met AutoSSL en elke serieuze Nederlandse WordPress-host. De host draait AutoSSL of iets equivalents tegen Let's Encrypt, het certificaat leeft in de configuratie van de host en niets van dat proces is zichtbaar voor jou, tenzij het misgaat. De eerlijke versie van dit verhaal is dat "automatisch" meestal ook echt automatisch is, totdat een DNS-wijziging of een .htaccess-rewrite de ACME HTTP-01 challenge breekt en de vernieuwing stilletjes faalt. Daar kom ik verderop op terug.

Route 2: cPanel of Plesk met AutoSSL. Hetzelfde verhaal als managed hosting, maar je kunt de AutoSSL-statuspagina in het controlepaneel wel zien. Zet de feature aan, voeg het domein toe, wacht op de volgende AutoSSL-run (meestal binnen 24 uur) en kijk hoe de status omschakelt naar "installed". Als AutoSSL weigert een certificaat uit te geven, vertelt het paneel je waarom, en de twee meest voorkomende redenen zijn dat het domein nog niet naar de server resolvet, of dat WordPress z'n eigen .htaccess het pad /.well-known/acme-challenge/ blokkeert. De fix voor dat tweede is een passende exclude-regel in .htaccess, boven het WordPress-blok.

Route 3: self-hosted met certbot. Op een VPS of dedicated server die je zelf configureert, is certbot de referentie-ACME-client. De certbot instructions lopen de exacte commando's per OS en webserver door en worden actueel gehouden. Het typische nginx-commando op een Debian-server is:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d jouwsite.nl -d www.jouwsite.nl

certbot voert de HTTP-01 challenge uit (plaatst een bestand onder /.well-known/acme-challenge/), valideert bij de servers van Let's Encrypt, installeert het certificaat in de nginx-configuratie en voegt een redirect toe van http:// naar https://. De renewal cronjob (/etc/cron.d/certbot of een systemd timer, afhankelijk van je OS) draait twee keer per dag en vernieuwt alleen als het certificaat binnen 30 dagen verloopt. Je kunt een dry-run doen zonder dat er daadwerkelijk een nieuw certificaat opgehaald wordt:

sudo certbot renew --dry-run

Je weet dat het werkt als de dry-run Congratulations, all simulated renewals succeeded afdrukt en het certificaat op schijf een verse Not After-datum laat zien:

sudo openssl x509 -in /etc/letsencrypt/live/jouwsite.nl/fullchain.pem -noout -enddate

Welke route je ook hebt gebruikt, WordPress moet daarna weten dat hij over HTTPS wordt geserveerd. In wp-admin > Instellingen > Algemeen moeten zowel "WordPress-adres (URL)" als "Site-adres (URL)" met https:// beginnen. Sinds WordPress 5.7 draait core een cronjob die twee keer per dag controleert of HTTPS daadwerkelijk bereikbaar is (wp_is_https_supported()), en op een site met bestaande HTTP-inhoud verschijnt er in Site Health een één-klik-migratieknop zodra HTTPS begint te werken. Die knop roept wp_update_urls_to_https() aan, dat de twee URL-opties bijwerkt, een verificatiecheck uitvoert en automatisch terugrolt als die check faalt. De vereiste capability is update_https, die standaard wordt toegekend aan elke gebruiker met zowel manage_options als update_core. Voor bestaande sites met content is het volledige redirect-verhaal (inclusief de Cloudflare Flexible valkuil en de reverse-proxy valkuil) te vinden in HTTPS afdwingen in WordPress.

Hoe je controleert of je certificaat écht actief is

Vier snelle checks. Voer ze alle vier uit na elke certificaatwijziging, en maak van de eerste twee een maandelijkse gewoonte.

1. Bekijk de Site Health van WordPress zelf. Ga naar wp-admin > Gereedschap > Websitediagnose. Sinds WordPress 5.7 meldt dat paneel expliciet of de site over HTTPS wordt geserveerd én of WordPress in staat was dat met zijn eigen cronjob te verifiëren. Als Site Health zegt "Your website does not use HTTPS" terwijl de browser duidelijk op https:// staat, faalt de probe van WordPress (meestal omdat de server een 403 of een redirect-lus teruggeeft op het probe-pad), en dat moet je eerst oplossen voordat je verder gaat.

2. Gebruik de SSL Labs-test voor een volledig extern beeld. De Qualys SSL Labs test haalt je site op, onderhandelt TLS, rapporteert de cipher suites, markeert zwakke configuraties en geeft je een cijfer van A tot F. Alles onder A- is het onderzoeken waard. Het rapport wordt een paar uur gecached, dus je kunt er niet snel mee itereren, maar het is wel het definitieve externe beeld. Geen software nodig, geen terminal nodig.

Als je SSH-toegang hebt, geven de volgende twee checks je meer detail dan de browsertools hierboven.

3. Curl de homepage en lees de headers. Draai curl -I https://jouwsite.nl/ vanuit een willekeurige terminal. Een gezond antwoord is HTTP/2 200 met een Strict-Transport-Security-header als je HSTS hebt geconfigureerd. Als curl een SSL-fout laat zien, is het certificaat fout (verlopen, hostnaam-mismatch, verkeerde chain), en je kunt curl om details vragen met curl -vI https://jouwsite.nl/ 2>&1 | grep -E 'SSL|issuer|subject'.

4. Inspecteer het certificaat direct met openssl. Dit toont je de uitgever, de datums en de subject alternative names (de lijst met hostnames die het certificaat dekt):

echo | openssl s_client -servername jouwsite.nl -connect jouwsite.nl:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

Wat je wilt zien is een issuer die Let's Encrypt bevat (of je eigen CA), een subject met je domein, een notBefore/notAfter-range die vandaag dekt en een SAN-lijst waarin alle hostnames staan die je bezoekers daadwerkelijk gebruiken (jouwsite.nl, www.jouwsite.nl en elk subdomein dat je over HTTPS serveert).

Veelvoorkomende certificaatproblemen en wat ze betekenen

De issues hieronder zijn degene die daadwerkelijk in een support-inbox belanden. Geen ervan gaat over gebroken encryptie. Alle gaan over identiteit, configuratie of automatisering.

"NET::ERR_CERT_DATE_INVALID" / certificaat verlopen. De Not After-datum van het certificaat ligt in het verleden. Op een self-hosted server betekent dit bijna altijd dat de renewal-cron van certbot niet draait, of dat de laatste vernieuwing stilletjes is gefaald en niemand de mail van Let's Encrypt heeft gelezen. Draai sudo certbot renew --dry-run; als die faalt, draai sudo certbot renew zonder de dry-run vlag en lees de échte foutmelding. De meest voorkomende oorzaak op een WordPress-host is een .htaccess-rewrite die /.well-known/acme-challenge/ opvangt voordat het challenge-bestand geserveerd kan worden. Op managed hosting: open een ticket. Op cPanel met AutoSSL: check de AutoSSL-logs in het paneel; de reden zit meestal één klik diep.

"NET::ERR_CERT_COMMON_NAME_INVALID" / verkeerd domein op het certificaat. De browser heeft de server wel bereikt, het certificaat is wel geldig, maar de hostnames in de SAN-lijst van het certificaat bevatten de hostname in de adresbalk niet. De twee veelvoorkomende oorzaken zijn (a) het certificaat is alleen voor jouwsite.nl uitgegeven, maar de bezoeker typt www.jouwsite.nl, of (b) iemand heeft het certificaat opnieuw uitgegeven en één van de hostnames vergeten. Vraag het certificaat opnieuw aan met certbot --nginx -d jouwsite.nl -d www.jouwsite.nl (of het equivalent bij je host), zodat beide namen gedekt zijn.

"NET::ERR_CERT_AUTHORITY_INVALID" / onbekende of onvertrouwde CA. De certificaatketen is kapot. Dat gebeurt als de webserver alleen het leaf-certificaat serveert en niet het intermediate, of als er per ongeluk een self-signed certificaat op een productiehost terecht is gekomen. Draai openssl s_client -servername jouwsite.nl -connect jouwsite.nl:443 -showcerts en kijk naar de chain. Zie je maar één certificaat, dan ontbreekt de intermediate. Voor door certbot beheerde certificaten: gebruik fullchain.pem, niet cert.pem, in je webserverconfiguratie. Voor alles anders: raadpleeg de documentatie van je host, want de fix is webserver-specifiek.

Auto-renewal faalt stilletjes op shared hosting. Dit is die ene waar mensen aan branden. Een host adverteert "automatische SSL-vernieuwing", de eerste vernieuwing werkt, en achttien maanden later verloopt het certificaat omdat AutoSSL al maanden stilletjes faalt en de notificatie naar een admin-mailbox ging die niemand leest. De oorzaken zijn bijna altijd dezelfde: de DNS is gewijzigd en het domein resolvet niet meer naar de host waar AutoSSL draait; een .htaccess-rewrite in WordPress blokkeert /.well-known/acme-challenge/; er staat nog een ouder certificaat in het paneel en AutoSSL weigert dat te overschrijven. De enige verdediging is een maandelijkse agenda-reminder om curl -I https://jouwsite.nl/ te draaien en de Not After uit openssl s_client met je ogen te lezen, of een externe uptime monitor zoals Better Stack of UptimeRobot met een certificaat-verloopalert op 30 dagen vooraf.

"SSL staat geïnstalleerd, maar de site is nog steeds niet veilig." Als de browser een kapot slotje of "Niet veilig" laat zien terwijl het certificaat geldig is en de datums kloppen, kijk je naar mixed content: een HTTPS-pagina die een HTTP-subresource laadt (een afbeelding, een script, een stylesheet). Het certificaat is prima; sommige URL's binnen je pagina's wijzen nog naar http://. De volledige fix staat in mixed content in WordPress.

Drie SSL-misvattingen die je mag afbranden

"Gratis SSL is minder veilig dan betaalde SSL." Onwaar op het cryptografische niveau, en de bron is een betaalde CA. GlobalSign geeft het zelf toe: beide niveaus bieden identieke encryptie. Wat je koopt met een betaald certificaat is een diepere identiteitscontrole, een warranty in de vijf tot zeven cijfers, technische support en historisch gezien een langere geldigheidsduur (een gat dat dichtloopt omdat CA/B Forum-regels de levensduur voor elke CA verkorten). Versleutelingssterkte staat niet in dat lijstje. Voor de overgrote meerderheid van WordPress-sites bieden een gratis Let's Encrypt DV-certificaat en een betaald DV-certificaat bezoekers precies dezelfde bescherming, en het gratis exemplaar is gemakkelijker om vernieuwd te houden.

"Het slotje betekent dat de site veilig is." Het slotje betekent dat het transport versleuteld is en dat de server aan de andere kant heeft bewezen dat hij het domein beheert. Het zegt niets over of de site door iemand wordt gerund die je kunt vertrouwen, of de applicatie op de server veilig is, of dat jouw data verantwoord wordt behandeld na aankomst. Phishingsites gebruiken gewoon gratis DV-certificaten. Het slotje is geen vertrouwenssignaal, het is een privacy-signaal. Een WordPress-site met SSL en een verouderde plugin is in de eerste week na de volgende CVE alsnog gecompromitteerd. Voor het volledige controleset zie WordPress beveiliging verharden.

"SSL vernieuwt automatisch." Het vernieuwt automatisch als de renewal-infrastructuur gezond is, en het faalt stilletjes als die infrastructuur breekt. Op een self-hosted VPS met certbot en een werkende cron is auto-renewal echt betrouwbaar. Op shared hosting met AutoSSL is het een best-effort-proces dat afhangt van DNS, .htaccess én van de host die actief z'n logs leest. Het enige wat auto-renewal écht automatisch maakt, is een monitor die je out-of-band vertelt wanneer het ophoudt te werken.

Een gevolg van een ontbrekend of verkeerd geconfigureerd SSL-certificaat dat webshop-eigenaren verrast: WooCommerce betaalgateways verbergen zichzelf stilzwijgend van de afrekenpagina wanneer SSL niet actief is. Als een betaalgateway is verdwenen na een certificaatwijziging of -verlopen, zie de gids voor ontbrekende WooCommerce-betaalgateways.

Wanneer je hulp moet inroepen

Bel je host of een specialist als een van de volgende dingen waar is. Verzamel eerst de lijst hieronder; elke minuut die ze besparen aan context is een minuut dichter bij een werkende site.

• De browser toont een certificaatfout en een zelftest met openssl s_client bevestigt dat het certificaat verlopen, verkeerd-domein of onvertrouwd is, en een vernieuwingspoging faalt óf lost de fout niet op.
• Het certificaat is geldig maar browsers tonen nog steeds "Niet veilig" nadat je mixed content al hebt opgelost.
• Je leunt op AutoSSL op shared hosting en het paneel meldt een vernieuwingsfout die je in één keer niet kunt oplossen.
• Je ziet een certificaat-mismatch tussen jouwsite.nl en www.jouwsite.nl die je zelf niet kunt repareren.

Verzamel voordat je vraagt:

• De exacte browserfoutmelding (een screenshot is prima).
• Je WordPress-versie en of de twee URL's in wp-admin > Instellingen > Algemeen met https:// beginnen.
• De Site Health-status uit wp-admin > Gereedschap > Websitediagnose (maak een screenshot van de HTTPS-gerelateerde items).
• De host en het controlepaneel (cPanel, Plesk, custom), en of je SSH-toegang hebt.
• De laatste keer dat het certificaat aantoonbaar succesvol is vernieuwd, als je die datum hebt.
• Of Cloudflare of een andere reverse proxy voor de site staat, en in welke SSL-modus (Flexible, Full, Full Strict).
• Als je SSH-toegang hebt: de output van curl -vI https://jouwsite.nl/ 2>&1 | head -60 en echo | openssl s_client -servername jouwsite.nl -connect jouwsite.nl:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates -ext subjectAltName.

Als je certificaat-situatie op orde is maar je WordPress-URL's weigeren nog steeds om naar HTTPS te flippen, dan is de volgende stop HTTPS afdwingen in WordPress. Als het slotje kapot is en het certificaat zelf gezond, dan is de volgende stop mixed content in WordPress. En als je over SSL nadenkt als één laag in een bredere verdediging, dan is de pillar WordPress beveiliging verharden.