«Tilkoblingen din er ikke privat»: advarselen om SSL-sertifikatet

Hva feilen betyr

Nettleseren koblet til serveren, serveren presenterte sertifikatet sitt, og nettleseren nektet å stole på det. Chrome viser «Tilkoblingen din er ikke privat» med en feilkode under; Firefox «Advarsel: Mulig sikkerhetsrisiko forut»; Safari «Denne tilkoblingen er ikke privat». Nettsiden er ikke hacket og datamaskinen din er ikke infisert; sertifikatet serveren sendte, består ikke kontrollene en nettleser gjør.

Feilkoden forteller deg hvilken kontroll som feilet:

• NET::ERR_CERT_DATE_INVALID: sertifikatet har utløpt, eller startdatoen ligger i fremtiden (eller klokken til den besøkende er feil).
• NET::ERR_CERT_COMMON_NAME_INVALID: sertifikatet gjelder et annet navn, for eksempel for www.example.com men ikke for example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: nettleseren kan ikke spore sertifikatet til en klarert utsteder: selvsignert, en ukjent utsteder eller et manglende mellomsertifikat.
• NET::ERR_CERT_REVOKED: sertifikatet ble tilbakekalt av utstederen.
• SSL_ERROR_BAD_CERT_DOMAIN og SEC_ERROR_EXPIRED_CERTIFICATE er Firefox sine versjoner av navne- og datofeilene.

Vanlige årsaker

1. Sertifikatet har utløpt. Let's Encrypt-sertifikater varer i 90 dager; den automatiske fornyelsen feilet i ukevis og ingen la merke til det før dagen det gikk ut. Betalte sertifikater utløper etter ett år, og fornyelsesposten gikk til en gammel adresse.
2. Fornyet, men ikke lastet på nytt. certbot skrev det nye sertifikatet til disk, men webserveren serverer fortsatt det gamle fra minnet, fordi reload-kroken mangler.
3. Feil navn. Sertifikatet dekker example.com, men besøkende kommer til www.example.com, eller et nytt underdomene ble lagt til uten sertifikat.
4. Manglende mellomsertifikat. Serveren sender bare sitt eget sertifikat, ikke kjeden. Nettlesere på pc fyller ofte hullet fra cachen; mobiler og apper feiler.
5. Et klokkeproblem. På den besøkendes datamaskin får en feil dato hvert sertifikat til å se utløpt eller ikke gyldig ennå ut. På serveren ødelegger en feil klokke fornyelsen.
6. Et CDN eller en proxy foran med eget sertifikat som har utløpt eller ikke dekker navnet, mens opprinnelsesserveren er fin.

Hvis du er besøkende

Sjekk først datoen og klokkeslettet på datamaskinen din; et dødt CMOS-batteri eller avslått tidssynkronisering får hver nettside til å feile. Prøv deretter et annet nettverk. Dukker advarselen opp for bare én nettside og på alle enheter, er nettsidens sertifikat problemet og eieren må fikse det. Å klikke seg gjennom «Fortsett til nettstedet (usikkert)» er greit for en nettside du kjenner, ikke for noe med innlogging eller betaling.

Hvis det er din nettside: sjekk først

Kjør SSL-sjekken. Den viser utløpsdatoen, navnene sertifikatet er gyldig for og om kjeden er komplett, utenfra, uten noen nettlesercache. Deretter, på din egen server:

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

# hva ligger på disken?
sudo certbot certificates

# er serverklokken riktig?
timedatectl

Er datoene på disken nyere enn datoene serveren sender, har du tilfelle 2: fornyet men ikke lastet på nytt.

Løsninger på din egen server

1. Forny med certbot

sudo certbot renew
# eller, hvis renew sier "not yet due" men sertifikatet som serveres er gammelt:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # eller apache2

Feiler fornyelsen, sier utdataene hvorfor. De vanlige grunnene: port 80 er blokkert eller omdirigert et sted certbot ikke forventer (HTTP-01-utfordringen trenger at /.well-known/acme-challenge/ kan nås over vanlig HTTP), DNS-posten peker på en annen server, eller en rate limit ble truffet etter mange mislykkede forsøk. Fiks årsaken og kjør sudo certbot renew --dry-run til den går gjennom.

2. Gjør reload automatisk

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

# legg til en deploy hook slik at webserveren plukker opp det nye sertifikatet
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. Legg til det manglende navnet

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

Flagget --expand erstatter det eksisterende sertifikatet med ett som dekker alle de oppførte navnene.

4. Rett kjeden

Med certbot peker du webserveren til fullchain.pem, aldri til 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 kjøpt sertifikat laster du ned mellomsertifikatet («CA bundle») fra utstederen og føyer det til sertifikatfilen. Test med sudo nginx -t (Apache: sudo apachectl configtest), last på nytt, og sjekk deretter kjeden med SSL-sjekken.

5. Rett klokken

sudo timedatectl set-ntp true
timedatectl

En server hvis klokke er av med mer enn noen få minutter, feiler sertifikatvalideringen i begge retninger.

6. Delt hosting eller nettstedsbygger

De fleste hosting-leverandører utsteder og fornyer Let's Encrypt-sertifikater fra kontrollpanelet («SSL/TLS», «Sikkerhet», «Let's Encrypt»). Åpne det, sjekk at sertifikatet dekker både example.com og www.example.com, og klikk forny eller utsted på nytt. Sier panelet at sertifikatet er gyldig men nettlesere er uenige, har hosting-leverandøren et reload- eller kjedeproblem hos seg.

Når det er hosting-leverandørens problem

Hei, siden omtrent 06:00 UTC viser nettlesere «Tilkoblingen din er ikke privat» (NET::ERR_CERT_DATE_INVALID) for nettsiden min example.com. Kontrollpanelet viser et gyldig sertifikat, så webserveren ser ut til å servere et gammelt. Kan dere laste sertifikatet på nytt på serveren og sjekke den automatiske fornyelsen for domenet mitt?

Forhindre neste gang

Et utløpt sertifikat er det ene driftsstoppet med en kjent dato. SSL-sertifikatovervåking varsler deg før utløpet, og igjen hvis kjeden eller navnet er feil; 5 sjekker er gratis. På din egen server fornyer en Quick Fix sertifikatet der certbot er satt opp og laster webserveren på nytt, til fast pris; en Deep Fix setter opp fornyelse der det ikke finnes noen ennå.