“Din forbindelse er ikke privat”: advarslen om SSL-certifikatet

Hvad fejlen betyder

Browseren forbandt til serveren, serveren fremviste sit certifikat, og browseren nægtede at stole på det. Chrome viser “Din forbindelse er ikke privat” med en fejlkode nedenunder; Firefox “Advarsel: Potentiel sikkerhedsrisiko forude”; Safari “Denne forbindelse er ikke privat”. Hjemmesiden er ikke hacket, og din computer er ikke smittet; det certifikat, serveren sendte, består ikke de kontroller, en browser foretager.

Fejlkoden fortæller dig, hvilken kontrol der fejlede:

• NET::ERR_CERT_DATE_INVALID: certifikatet er udløbet, eller dets startdato ligger i fremtiden (eller den besøgendes ur er forkert).
• NET::ERR_CERT_COMMON_NAME_INVALID: certifikatet er til et andet navn, for eksempel til www.example.com, men ikke til example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: browseren kan ikke føre certifikatet tilbage til en betroet udsteder: selvsigneret, en ukendt udsteder eller et manglende mellemcertifikat.
• NET::ERR_CERT_REVOKED: certifikatet blev tilbagekaldt af sin udsteder.
• SSL_ERROR_BAD_CERT_DOMAIN og SEC_ERROR_EXPIRED_CERTIFICATE er Firefox’ udgaver af navne- og datofejlene.

Almindelige årsager

1. Certifikatet er udløbet. Certifikater fra Let’s Encrypt gælder i 90 dage; den automatiske fornyelse fejlede i ugevis, og ingen opdagede det før den dag, det løb ud. Betalte certifikater udløber efter et år, og påmindelsen om fornyelse gik til en gammel adresse.
2. Fornyet, men ikke genindlæst. certbot skrev det nye certifikat til disken, men webserveren leverer stadig det gamle fra hukommelsen, fordi reload-hooken mangler.
3. Forkert navn. Certifikatet dækker example.com, men besøgende kommer til www.example.com, eller et nyt underdomæne blev tilføjet uden certifikat.
4. Manglende mellemcertifikat. Serveren sender kun sit eget certifikat, ikke kæden. Browsere på computere udfylder ofte hullet fra cachen; telefoner og apps fejler.
5. Et urproblem. På den besøgendes computer får en forkert dato hvert certifikat til at se udløbet eller endnu ikke gyldigt ud. På serveren ødelægger et forkert ur fornyelsen.
6. Et CDN eller en proxy foran med sit eget certifikat, som er udløbet eller ikke dækker navnet, mens origin er i orden.

Hvis du er besøgende

Tjek først din computers dato og klokkeslæt; et dødt CMOS-batteri eller en deaktiveret tidssynkronisering får alle hjemmesider til at fejle. Prøv så et andet netværk. Optræder advarslen kun for én hjemmeside og på alle enheder, er hjemmesidens certifikat problemet, og ejeren må rette det. At klikke videre via “Fortsæt til webstedet (usikkert)” er i orden for en hjemmeside, du kender, ikke for noget med login eller betaling.

Hvis det er din hjemmeside: tjek først

Kør SSL-checkeren. Den viser udløbsdatoen, de navne, certifikatet er gyldigt for, og om kæden er komplet, udefra, uden nogen browsercache. Derefter, på din egen server:

# hvad sender serveren egentlig?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# hvad ligger på disken?
sudo certbot certificates

# er serverens ur rigtigt?
timedatectl

Er datoerne på disken nyere end de datoer, serveren sender, har du tilfælde 2: fornyet, men ikke genindlæst.

Rettelser på din egen server

1. Forny med certbot

sudo certbot renew
# eller, hvis renew siger "not yet due", men det leverede certifikat er gammelt:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # eller apache2

Fejler fornyelsen, siger outputtet hvorfor. De sædvanlige grunde: port 80 er blokeret eller omdirigeret et sted, certbot ikke forventer (HTTP-01-udfordringen kræver, at /.well-known/acme-challenge/ kan nås over almindelig HTTP), DNS-recorden peger på en anden server, eller en rate limit er ramt efter mange mislykkede forsøg. Ret årsagen, og kør sudo certbot renew --dry-run, til den består.

2. Gør genindlæsningen automatisk

# Debian/Ubuntu: certbot installerer en timer; tjek den
systemctl list-timers | grep certbot

# tilføj en deploy hook, så webserveren henter det nye certifikat
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. Tilføj det manglende navn

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

Flaget --expand erstatter det eksisterende certifikat med et, der dækker alle opregnede navne.

4. Ret kæden

Med certbot skal du pege webserveren på fullchain.pem, aldrig på cert.pem:

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

Apache: SSLCertificateFile med fullchain.pem. Med et købt certifikat henter du mellemcertifikatet (“CA bundle”) hos udstederen og føjer det til certifikatfilen. Test med sudo nginx -t (Apache: sudo apachectl configtest), genindlæs, og tjek så kæden med SSL-checkeren.

5. Ret uret

sudo timedatectl set-ntp true
timedatectl

En server, hvis ur er forkert med mere end nogle få minutter, fejler certifikatvalideringen i begge retninger.

6. Delt hosting eller hjemmesidebygger

De fleste hostingudbydere udsteder og fornyer Let’s Encrypt-certifikater fra kontrolpanelet (“SSL/TLS”, “Sikkerhed”, “Let’s Encrypt”). Åbn det, tjek, at certifikatet dækker både example.com og www.example.com, og klik på forny eller udsted igen. Siger panelet, at certifikatet er gyldigt, men browsere er uenige, har hostingudbyderen et problem med genindlæsning eller kæde hos sig.

Når det er din hostingudbyders problem

Hej, siden ca. kl. 06:00 UTC viser browsere “Din forbindelse er ikke privat” (NET::ERR_CERT_DATE_INVALID) for min hjemmeside example.com. Kontrolpanelet viser et gyldigt certifikat, så webserveren ser ud til at levere et gammelt. Kan I genindlæse certifikatet på serveren og tjekke den automatiske fornyelse for mit domæne?

Forebyg den næste

Et udløbet certifikat er det ene nedbrud med en kendt dato. Overvågning af SSL-certifikater advarer dig før udløbet og igen, hvis kæden eller navnet er forkert; 5 tjek er gratis. På din egen server fornyer en Quick Fix certifikatet, hvor certbot er sat op, og genindlæser webserveren, til fast pris; en Deep Fix sætter fornyelse op, hvor der endnu ingen er.