"Din anslutning är inte privat": vad felet betyder och hur du åtgärdar det

Du klickar på en länk, väntar dig en välbekant sida - och i stället fyller Chrome skärmen med en varning: "Din anslutning är inte privat." Under den står en kryptisk kod som NET::ERR_CERT_AUTHORITY_INVALID. Oavsett om du är besökare eller webbplatsägare som ser trafiken försvinna går felet nästan alltid att åtgärda på några minuter - bara du vet vilken av en handfull orsaker som ligger bakom.

Varningen är inte skadlig kod, och den betyder inte att du blivit hackad. Den betyder att webbläsaren försökte upprätta en krypterad HTTPS-anslutning men inte kunde verifiera webbplatsens SSL/TLS-certifikat. Certifikatet är webbplatsens id-handling, och hellre än att riskera att skicka dina uppgifter till en bedragare vägrar webbläsaren att visa sidan.

Den här guiden förklarar vad som utlöser varningen, hur besökare blir av med den i sju snabba steg och hur webbplatsägare diagnostiserar och åtgärdar den permanent - plus varför en branschomfattande förändring av certifikatens livslängd gör att felet blir vanligare från 2026 och framåt.

Vad varningen faktiskt betyder

Över 95 % av alla sidor som laddas i Chrome levereras via HTTPS, enligt Googles transparensrapport. HTTPS gör två saker: krypterar trafiken och bevisar att servern verkligen är den som står i adressfältet. Beviset är TLS-certifikatet, som webbläsaren validerar vid varje anslutning. Tre kontroller måste alla gå igenom:

1. Förtroende - certifikatet är utfärdat av en certifikatutfärdare (CA) som din enhet litar på.
2. Giltighet - dagens datum ligger inom certifikatets giltighetstid.
3. Identitet - domänen i adressfältet matchar ett namn i certifikatet.

Om någon kontroll misslyckas blockerar webbläsaren sidan och visar varningen i stället. Kryptering utan verifierad identitet är värdelös - en angripare på öppet Wi‑Fi skulle annars i tysthet kunna dekryptera allt du skickar.

Samma fel i alla webbläsare

Webbläsarna formulerar varningen olika, men certifikatproblemet bakom är identiskt.

Koden längst ner i varningen är din bästa ledtråd:

• NET::ERR_CERT_DATE_INVALID - certifikatet har gått ut, eller så går enhetens klocka fel.
• NET::ERR_CERT_AUTHORITY_INVALID - utfärdaren är inte betrodd: självsignerat certifikat, ofullständig certifikatkedja eller antivirus/proxy som avlyssnar trafiken.
• NET::ERR_CERT_COMMON_NAME_INVALID - certifikatet täcker inte exakt den här domänen, t.ex. täcker det www.example.com men inte example.com.
• NET::ERR_CERT_REVOKED - utfärdaren har återkallat certifikatet, ofta efter att en nyckel läckt.

Är du besökare? 7 lösningar, snabbast först

1. Ladda om sidan och testa i inkognitoläge. Det utesluter cachade certifikat och strulande tillägg.
2. Kontrollera enhetens datum och tid. En klocka som går fel med månader får alla giltiga certifikat att se utgångna ut. Slå på automatisk tid. Detta ensamt löser en stor andel av alla DATE_INVALID-fel.
3. På öppet Wi‑Fi: logga in på nätverket först. Captive portals på hotell och flygplatser kapar alla anrop tills du autentiserat dig, vilket bryter HTTPS. Besök en ren HTTP-sida som http://neverssl.com för att tvinga fram inloggningssidan.
4. Uppdatera webbläsare och operativsystem. Rotcertifikat följer med OS- och webbläsaruppdateringar; riktigt gamla enheter känner inte igen dagens utfärdare - ödet för många Android-telefoner före 7.1.1 efter Let's Encrypts rotbyte.
5. Stäng tillfälligt av HTTPS-skanning i antivirusprogrammet. Säkerhetssviter som inspekterar krypterad trafik signerar om den med eget certifikat; när det går fel får du AUTHORITY_INVALID på alla webbplatser. Försvinner varningen: slå på funktionen igen och uppdatera eller konfigurera om programmet.
6. Rensa webbläsarens cache och SSL-tillstånd. I Chrome: Inställningar → Integritet och säkerhet → Rensa webbinformation.
7. Felar det fortfarande på en enda webbplats - från alla enheter och nätverk? Då ligger problemet hos webbplatsen, inte hos dig. Klicka inte på "Fortsätt"; på en inloggnings- eller betalsida är det precis den risken varningen ska skydda mot.

Är det din webbplats? Diagnostisera, åtgärda, automatisera

Börja med att se vad certifikatet faktiskt säger. Från valfri terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Eller hoppa över kommandoraden: en gratis FortifyNet-skanning läser certifikat, kedja och TLS-konfiguration på cirka 60 sekunder och talar om exakt vad som är fel.

Med Let's Encrypt, som kostnadsfritt säkrar hundratals miljoner webbplatser, finns ingen anledning att köra produktion på självsignerade certifikat. En typisk installation på nginx:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Certbot installerar certifikatet med komplett kedja och schemalägger automatisk förnyelse - det enskilt bästa skyddet mot att någonsin visa den här varningen.

Därför blir felet snart vanligare

I april 2025 antog CA/Browser Forum omröstningen SC-081v3, en tidsplan som krymper publika TLS-certifikats maximala livslängd från 398 dagar till bara 47 dagar år 2029, vilket DigiCert beskriver. Sedan den 15 mars 2026 får ingen publik CA utfärda certifikat som gäller längre än 200 dagar; i mars 2027 sänks taket till 100 dagar och i mars 2029 till 47.

Publika TLS-certifikats maximala livslängd 2018–2029. Källa: CA/Browser Forum, SC-081v3.

Den praktiska konsekvensen: en webbplats som förnyar certifikat manuellt måste göra det minst två gånger om året i dag, och runt åtta gånger om året från 2029. Varje manuellt steg är en chans att glömma - därför är automatisering plus utgångsbevakning numera grundkravet, inte ett trevligt extra.

Vanliga frågor

Är det någonsin säkert att klicka på "Fortsätt ändå"? Bara när du vet exakt varför varningen visas och inga känsliga uppgifter är inblandade - till exempel din egen routers adminpanel med självsignerat certifikat. Aldrig på bank-, e-post-, butiks- eller inloggningssidor.

Varför ser jag varningen när ingen annan gör det? Då är orsaken lokal: fel klocka, aggressivt antivirus, en captive portal eller ett föråldrat OS utan moderna rotcertifikat. Gå igenom besökarstegen 1–6 ovan.

Varför visar min webbplats felet bara på mobiler? Klassiskt tecken på ofullständig certifikatkedja. Datorwebbläsare cachar ofta saknade mellancertifikat; mobilwebbläsare är strängare. Konfigurera servern att skicka hela kedjan.

Påverkar varningen SEO och trafik? Direkt: de flesta besökare lämnar omedelbart, eftersom det krävs två medvetna klick för att ta sig förbi. Indirekt: HTTPS är en rankningssignal hos Google, och långvariga certifikatfel drar ner både crawlning och konvertering.

Relaterade guider

• SSL-certifikat A+ betyg i SSL Labs: Komplett guide 2026
• SSL-certifikat: A+ betyg i SSL Labs – komplett guide
• Sårbarhetsskanner för webbplatser: vad den kontrollerar

Upptäck certifikatproblem innan dina besökare gör det

Varningen besökarna ser är det sista symptomet på ett problem som gick att upptäcka veckor tidigare. Kör en gratis FortifyNet-skanning - 60 sekunder, ingen registrering - och få en tydlig rapport om certifikatets utgångsdatum, kedjan, TLS-konfigurationen, säkerhetsheaders, DNS och e-postautentisering.