Wat “Je verbinding is niet privé” betekent en hoe je het oplost

Wat de fout betekent

De browser heeft verbinding gemaakt, de server heeft zijn certificaat getoond en de browser heeft geweigerd het te vertrouwen. Chrome toont “Je verbinding is niet privé” met een foutcode (oudere versies zeiden “Uw verbinding is niet privé”); Firefox zegt “Waarschuwing: mogelijk beveiligingsrisico”; Safari “Deze verbinding is niet privé”. De site is niet gehackt en je apparaat is niet besmet: het certificaat dat de server stuurt, komt niet door de controles van de browser.

De foutcode zegt welke controle mislukte:

• NET::ERR_CERT_DATE_INVALID: het certificaat is verlopen of nog niet geldig (of de klok van de bezoeker staat fout).
• NET::ERR_CERT_COMMON_NAME_INVALID: het certificaat geldt voor een andere naam, bijvoorbeeld www.example.com maar niet example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: geen erkende instantie staat ervoor in: zelfondertekend, onbekende uitgever of een ontbrekend tussencertificaat.
• NET::ERR_CERT_REVOKED: de uitgever heeft het certificaat ingetrokken.
• SSL_ERROR_BAD_CERT_DOMAIN en SEC_ERROR_EXPIRED_CERTIFICATE: de varianten van Firefox voor naam en datum.

Veelvoorkomende oorzaken

1. Het certificaat is verlopen. Certificaten van Let’s Encrypt gelden 90 dagen; de automatische vernieuwing mislukte al weken en niemand zag het tot de dag dat het verliep. Gekochte certificaten verlopen na een jaar, en de herinnering kwam aan op een oud e-mailadres.
2. Vernieuwd, maar niet herladen. certbot heeft het nieuwe certificaat op schijf gezet, maar de webserver serveert nog het oude omdat de reload-hook ontbreekt.
3. Verkeerde naam. Het certificaat dekt example.com, maar bezoekers komen via www.example.com, of een subdomein heeft geen certificaat.
4. Het tussencertificaat ontbreekt. De server stuurt alleen zijn eigen certificaat, niet de keten. Desktopbrowsers vullen het gat vaak zelf op; telefoons en apps lopen vast.
5. Een klokprobleem. Bij de bezoeker laat een verkeerde datum alle certificaten verlopen lijken. Op de server breekt het de vernieuwing.
6. Een CDN of proxy ervoor met een eigen certificaat dat verlopen is of de juiste naam mist, terwijl de origin-server in orde is.

Als je bezoeker bent

Controleer eerst datum en tijd van je apparaat; een lege klokbatterij of uitgeschakelde tijdsynchronisatie laat elke site mislukken. Probeer daarna vanaf een ander netwerk. Verschijnt de waarschuwing maar op één site, vanaf elk apparaat, dan ligt het aan het certificaat van die site: dat moet de eigenaar oplossen. Klikken op “Doorgaan naar … (onveilig)” is prima voor een site die je kent, nooit voor een site met wachtwoorden of betalingen.

Als het je eigen site is: eerst controleren

Open de SSL checker: vervaldatum, gedekte namen en of de keten volledig is, van buitenaf en zonder browsercache. Daarna op je server:

# wat stuurt de server?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# wat staat er op schijf?
sudo certbot certificates

# staat de klok goed?
timedatectl

Nieuwere datums op schijf dan in het antwoord van de server? Dan zit je in geval 2: vernieuwd, maar niet herladen.

Oplossingen op je eigen server

1. Vernieuwen met certbot

sudo certbot renew
# als renew "not yet due" zegt terwijl de server een oud certificaat serveert:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # of apache2

Mislukt de vernieuwing, dan staat de reden in de uitvoer. De klassiekers: poort 80 is geblokkeerd of wordt doorverwezen (de HTTP-01-challenge moet via gewoon HTTP bij /.well-known/acme-challenge/ aankomen), het DNS wijst ergens anders heen, of er geldt een limiet na te veel mislukte pogingen. Verhelp de oorzaak en draai sudo certbot renew --dry-run tot het slaagt.

2. Het herladen automatiseren

# certbot installeert een timer; controleer hem
systemctl list-timers | grep certbot

# hook zodat de webserver het nieuwe certificaat oppakt
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. De ontbrekende naam toevoegen

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com --expand

--expand vervangt het bestaande certificaat door een certificaat dat alle genoemde namen dekt.

4. De keten repareren

Met certbot moet de webserver naar fullchain.pem wijzen, nooit naar cert.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache: SSLCertificateFile met fullchain.pem. Voor een gekocht certificaat download je de “CA bundle” van de uitgever en plak je die achter het bestand. Test met sudo nginx -t (Apache: sudo apachectl configtest), herlaad en controleer de keten met de SSL checker.

5. De klok gelijkzetten

sudo timedatectl set-ntp true
timedatectl

Een klok die meer dan een paar minuten afwijkt, laat de certificaatcontrole in beide richtingen mislukken.

6. Shared hosting of websitebouwer

De meeste hostingproviders geven Let’s Encrypt-certificaten uit en vernieuwen ze vanuit het klantenpaneel (“SSL/TLS”, “Security”, “Let’s Encrypt”). Open dat en controleer daar of het certificaat example.com én www.example.com dekt, en klik op vernieuwen of opnieuw uitgeven. Toont het paneel een geldig certificaat terwijl browsers het tegendeel zeggen, dan zit het reload- of ketenprobleem bij de hostingprovider.

Als het probleem bij je hostingprovider ligt

Goedemorgen, sinds ongeveer 6:00 uur (UTC) tonen browsers “Je verbinding is niet privé” (NET::ERR_CERT_DATE_INVALID) op mijn website example.com. Het klantenpaneel toont een geldig certificaat, dus de server lijkt nog het oude te serveren. Kunt u het certificaat opnieuw laden en de automatische vernieuwing voor mijn domein controleren?

Zodat het niet opnieuw gebeurt

Een verlopen certificaat is de enige storing met een datum die vooraf bekend is. De SSL-certificaat monitoring waarschuwt je vóór de vervaldatum, en ook als de keten of de naam niet klopt; het gratis plan bevat de SSL-controles. Komt de browser niet eens toe aan het certificaat en toont hij ERR_SSL_PROTOCOL_ERROR? Dat is een ander geval: de veilige verbinding mislukt nog vóór het certificaat. En weigert de server de verbinding op poort 443 meteen? Dan is het een ERR_CONNECTION_REFUSED.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang vernieuwt de Quick Fix het certificaat waar certbot is ingesteld en herlaadt hij de webserver, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix zet de vernieuwing op waar die ontbreekt, per blok van 15 minuten; de schatting is de bovengrens.