”Anslutningen är inte privat”: varningen för SSL-certifikat

Vad felet betyder

Webbläsaren anslöt till servern, servern visade upp sitt certifikat, och webbläsaren vägrade lita på det. Chrome visar ”Anslutningen är inte privat” med en felkod under; Firefox ”Varning: Potentiell säkerhetsrisk framöver”; Safari ”Den här anslutningen är inte privat”. Hemsidan är inte hackad och din dator är inte infekterad; certifikatet som servern skickade klarar inte kontrollerna som en webbläsare gör.

Felkoden talar om vilken kontroll som misslyckades:

• NET::ERR_CERT_DATE_INVALID: certifikatet har gått ut, eller dess startdatum ligger i framtiden (eller besökarens klocka är fel).
• NET::ERR_CERT_COMMON_NAME_INVALID: certifikatet gäller ett annat namn, till exempel för www.example.com men inte för example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: webbläsaren kan inte spåra certifikatet till en betrodd utfärdare: självsignerat, en okänd utfärdare eller ett saknat mellanliggande certifikat.
• NET::ERR_CERT_REVOKED: certifikatet återkallades av sin utfärdare.
• SSL_ERROR_BAD_CERT_DOMAIN och SEC_ERROR_EXPIRED_CERTIFICATE är Firefox varianter av namn- och datumfelen.

Vanliga orsaker

1. Certifikatet gick ut. Let's Encrypt-certifikat gäller i 90 dagar; den automatiska förnyelsen misslyckades i veckor och ingen märkte det förrän dagen det tog slut. Betalda certifikat går ut efter ett år och förnyelsemejlet gick till en gammal adress.
2. Förnyat, men inte omladdat. certbot skrev det nya certifikatet till disk, men webbservern visar fortfarande det gamla från minnet, eftersom omladdningskroken saknas.
3. Fel namn. Certifikatet täcker example.com men besökare kommer till www.example.com, eller så lades en ny underdomän till utan certifikat.
4. Saknat mellanliggande certifikat. Servern skickar bara sitt eget certifikat, inte kedjan. Webbläsare på dator fyller ofta luckan från cachen; mobiler och appar misslyckas.
5. Ett klockproblem. På besökarens dator får ett felaktigt datum varje certifikat att se utgånget eller ännu inte giltigt ut. På servern förstör en felaktig klocka förnyelsen.
6. Ett CDN eller en proxy framför med eget certifikat som gått ut eller inte täcker namnet, medan origin är i ordning.

Om du är besökare

Kontrollera först datum och tid på din dator; ett dött CMOS-batteri eller avstängd tidssynkronisering får varje hemsida att misslyckas. Prova sedan ett annat nätverk. Om varningen visas för bara en hemsida och på alla enheter är hemsidans certifikat problemet och ägaren måste åtgärda det. Att klicka sig igenom ”Fortsätt till webbplatsen (osäkert)” går bra för en hemsida du känner, inte för något med inloggning eller betalning.

Om det är din hemsida: kontrollera först

Kör SSL-kontrollen. Den visar utgångsdatumet, namnen som certifikatet är giltigt för och om kedjan är komplett, utifrån, utan någon webbläsarcache. Sedan, på din egen server:

# vad skickar servern egentligen?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# vad finns på disken?
sudo certbot certificates

# är serverns klocka rätt?
timedatectl

Om datumen på disken är nyare än datumen som servern skickar har du fall 2: förnyat men inte omladdat.

Åtgärder på din egen server

1. Förnya med certbot

sudo certbot renew
# eller, om renew säger "not yet due" men certifikatet som visas är gammalt:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # eller apache2

Om förnyelsen misslyckas säger utdata varför. De vanliga skälen: port 80 är blockerad eller omdirigerad till något som certbot inte förväntar sig (HTTP-01-utmaningen kräver att /.well-known/acme-challenge/ går att nå över vanlig HTTP), DNS-posten pekar på en annan server, eller en hastighetsgräns nåddes efter många misslyckade försök. Åtgärda orsaken och kör sudo certbot renew --dry-run tills den går igenom.

2. Gör omladdningen automatisk

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

# lägg till en deploy-krok så att webbservern plockar upp det nya certifikatet
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. Lägg till det saknade namnet

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

Flaggan --expand ersätter det befintliga certifikatet med ett som täcker alla listade namn.

4. Rätta kedjan

Med certbot, peka webbservern 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 ett köpt certifikat, ladda ner det mellanliggande certifikatet (”CA bundle”) från utfärdaren och lägg till det i certifikatfilen. Testa med sudo nginx -t (Apache: sudo apachectl configtest), ladda om och kontrollera sedan kedjan med SSL-kontrollen.

5. Rätta klockan

sudo timedatectl set-ntp true
timedatectl

En server vars klocka går fel med mer än några minuter misslyckas med certifikatvalideringen åt båda hållen.

6. Delat webbhotell eller webbplatsbygge

De flesta webbhotell utfärdar och förnyar Let's Encrypt-certifikat från kontrollpanelen (”SSL/TLS”, ”Säkerhet”, ”Let's Encrypt”). Öppna den, kontrollera att certifikatet täcker både example.com och www.example.com och klicka på förnya eller utfärda på nytt. Om panelen säger att certifikatet är giltigt men webbläsare är oense har webbhotellet ett problem med omladdning eller kedja hos sig.

När det är ditt webbhotells problem

Hej, sedan ungefär 06:00 UTC visar webbläsare ”Anslutningen är inte privat” (NET::ERR_CERT_DATE_INVALID) för min hemsida example.com. Kontrollpanelen visar ett giltigt certifikat, så webbservern verkar visa ett gammalt. Kan ni ladda om certifikatet på servern och kontrollera den automatiska förnyelsen för min domän?

Förhindra nästa

Ett utgånget certifikat är det enda driftstoppet med ett känt datum. Övervakning av SSL-certifikat varnar dig före utgången, och igen om kedjan eller namnet är fel; 5 kontroller är gratis. På din egen server förnyar en Quick Fix certifikatet där certbot är uppsatt och laddar om webbservern, till fast pris; en Deep Fix sätter upp förnyelse där det ännu inte finns någon.