ERR_CERT_AUTHORITY_INVALID: vad felet beror på och hur du åtgärdar det

ERR_CERT_AUTHORITY_INVALID betyder att webbläsaren inte kunde bygga en förtroendekedja från certifikatet som din server presenterade tillbaka till en rotutfärdare som den redan litar på. Chrome visar felet som NET::ERR_CERT_AUTHORITY_INVALID under skärmen "Din anslutning är inte privat". Det är nästan aldrig ett tecken på att certifikatet har gått ut, utan nästan alltid en av två saker: din server skickar inte sitt mellanliggande certifikat, eller så är certifikatet inte utfärdat av en publikt betrodd utfärdare alls. Åtgärden tar minuter när du väl vet på vilken sida felet ligger.

Vad felet faktiskt betyder

Varje TLS-certifikat valideras genom att man vandrar längs en kedja. Webbläsaren tar emot serverns certifikat (löv-certifikatet), läser av vilken utfärdare som signerat det och letar upp den utfärdaren. Om den signerande utfärdaren är ett mellancertifikat behöver webbläsaren även det, för att kunna kontrollera vem som signerat det, och så fortsätter vandringen tills den når ett rotcertifikat som redan finns installerat i förtroendelagret.

Om någon länk i den vandringen saknas, inte är signerad av en betrodd part, eller är utfärdad av en utfärdare som webbläsaren har tagit bort, kan kedjan inte slutföras och anslutningen nekas med ERR_CERT_AUTHORITY_INVALID.

Chrome levererar sin egen förtroendelista, Chrome Root Store, i stället för att bara förlita sig på operativsystemet. Firefox gör detsamma. Safari och Edge lutar sig mot operativsystemets lager. Den skillnaden är anledningen till att en webbplats kan misslyckas i en webbläsare och fungera i en annan på samma dator, och den är en av de mest användbara diagnossignaler du har.

De sju orsakerna, och var felet ligger

Orsak 1 och 2 står för den absoluta merparten av verkliga rapporter. Äger du webbplatsen bör du börja där.

Snabbdiagnos på 30 sekunder

Innan du ändrar något: ta reda på om problemet finns på servern eller på besökarens dator.

1. Öppna webbplatsen via mobildata, på en telefon som aldrig besökt den. Om den misslyckas där men fungerar på din dator saknas ett mellancertifikat. Skrivbordswebbläsare cachar mellancertifikat de sett tidigare och kan tyst reparera en trasig kedja, vilket är precis därför den här buggen kan leva oupptäckt så länge.
2. Testa en annan webbläsare på samma dator. Om det bara misslyckas i Chrome pekar det mot att Chrome Root Store avvisar utfärdaren. Om allt misslyckas på en dator pekar det mot avlyssning eller en föråldrad enhet.
3. Klicka på varningen, välj "Avancerat" och läs utfärdaren. Om utfärdaren är din antivirusprodukt, en brandväggsleverantör eller din arbetsgivares namn, avlyssnas och signeras trafiken om. Det är orsak 4, och det är inte din webbplats fel.
4. Kontrollera kedjan från kommandoraden med OpenSSL:

openssl s_client -connect exempel.se:443 -servername exempel.se -showcerts

Du bör se minst två certifikat i utdatan: ditt löv-certifikat och därefter ett eller flera mellancertifikat. Kommer bara ett certifikat tillbaka saknas mellancertifikatet, och du har hittat felet.

Åtgärd 1: installera hela certifikatkedjan

Detta är den absolut vanligaste orsaken på serversidan. Din utfärdare ger dig ett löv-certifikat och ett eller flera mellancertifikat, och servern måste skicka samtliga. Peka din webbserver mot hela kedjan i stället för enbart löv-certifikatet.

Använder du Let's Encrypt är åtgärden oftast ett enda ord: använd fullchain.pem, aldrig cert.pem. Let's Encrypt påpekar att varje certifikat de utfärdar har ett mellancertifikat som signerats direkt av deras mest betrodda rot, och att flera aktiva mellancertifikat roterar över tid, vilket gör det skört att hårdkoda en specifik mellancertifikatfil (Let's Encrypt, Chains of Trust). Ladda om servern efter ändringen; en konfigurationsändring gör ingenting förrän processen läser in den.

Åtgärd 2: byt ut ett självsignerat certifikat

Ett självsignerat certifikat signerar sig självt. Ingen publik utfärdare går i god för det, så ingen webbläsare kan någonsin lita på det utan manuellt ingripande. Det är korrekt beteende, inte en bugg.

För allt som är publikt tillgängligt: skaffa ett gratis certifikat från en publikt betrodd utfärdare och automatisera förnyelsen. För genuint interna verktyg: lägg antingen till din interna rot i förtroendelagret på de enheter som behöver den, eller utfärda från en intern CA som redan distribueras av er enhetshantering. Lär inte teamet att klicka förbi varningen; just den vanan är vad nätfiskare räknar med.

Åtgärd 3: uteslut avlyssning och föråldrade enheter

Om utfärdaren i varningen är en antivirusprodukt: stäng tillfälligt av dess HTTPS- eller SSL-granskning och ladda om. Många säkerhetspaket lägger in sin egen rot för att inspektera krypterad trafik, och en trasig eller utgången inspektionsrot slår ut alla HTTPS-webbplatser samtidigt.

På en föråldrad enhet: installera väntande operativsystemsuppdateringar. Rotlager levereras med systemuppdateringar, och en enhet som ligger flera år efter saknar nyare rötter helt. Kontrollera slutligen klockan: ett systemdatum som är kraftigt fel kan få en giltig rot att se ut som att den ännu inte är giltig, vilket visar sig som ett utfärdarfel i stället för ett datumfel.

Åtgärd 4: kontrollera om din utfärdare fortfarande är betrodd

Rotprogram tar bort utfärdare som inte uppfyller kraven, och de borttagningarna är verkliga händelser med verkliga tidsgränser. Chrome Root Program kräver att nyutfärdade publika TLS-certifikat från och med 15 juni 2026 endast bär serverAuth som utökad nyckelanvändning; certifikat som även bär clientAuth kommer inte längre att vara betrodda av Chrome, och CA-ägare vars hierarkier inte uppfyller kraven måste bygga om dem eller lämna lagret (Chrome Root Program Policy).

Om en webbplats plötsligt misslyckas i Chrome medan äldre klienter fortfarande accepterar den är en förtroendeborttagning en realistisk förklaring. Lösningen är att utfärda om från en utfärdare som uppfyller kraven.

Varför felet är på väg att bli vanligare

Certifikatens livslängd krymper snabbt. Enligt CA/Browser Forums omröstning SC-081v3, antagen i april 2025, trappas den maximala giltighetstiden ned från 398 dagar till 200 dagar den 15 mars 2026, till 100 dagar 2027 och till 47 dagar 2029 (CA/Browser Forum, Ballot SC-081v3).

Maximal livslängd för TLS-certifikat enligt CA/Browser Forums omröstning SC-081v3. Källa: CA/Browser Forum, april 2025.

Fler förnyelser innebär fler tillfällen då ett automatiseringsskript kan distribuera ett löv-certifikat utan sitt mellancertifikat. Varje förnyelse är numera en driftsättning, och varje driftsättning kan bryta kedjan. Team som förnyade manuellt en gång om året och sedan aldrig tänkte på saken kommer att träffa på det här felet för första gången under 2026.

Verifiera åtgärden

Efter att du ändrat kedjan: lita inte på din egen webbläsare. Den har cachat mellancertifikatet och visar dig ett grönt hänglås över en kedja som fortfarande misslyckas för alla andra. Verifiera från en ren utsiktspunkt: en extern skanner, en telefon på mobildata eller en helt ny webbläsarprofil. Bekräfta att löv-certifikatet och samtliga mellancertifikat levereras, och att inget mellancertifikat självt har gått ut.

Relaterade guider

• "Din anslutning är inte privat": vad felet betyder och hur du åtgärdar det täcker den bredare varningsskärm som det här felet visas under.
• ERR_SSL_PROTOCOL_ERROR: vad felet betyder och hur du åtgärdar det tar upp handskakningsfel som ser lika ut men har andra orsaker.
• SSL-certifikat A+ betyg i SSL Labs: komplett guide 2026 går igenom kedja, protokoll och chifferkonfiguration från början till slut.

Vanliga frågor

Är ERR_CERT_AUTHORITY_INVALID farligt för besökare? Det kan vara det. Webbläsaren säger att den inte kan verifiera vem den pratar med, vilket är precis det tillstånd en man-in-the-middle-attack skapar. På en webbplats du inte kontrollerar bör du ta varningen på allvar och inte gå vidare.

Varför fungerar webbplatsen på min dator men inte för mina kunder? Skrivbordswebbläsare cachar mellancertifikat från tidigare besök och kan slutföra en trasig kedja ur minnet. Enheter som aldrig sett mellancertifikatet kan inte det. Den asymmetrin är den klassiska signaturen för ett saknat mellancertifikat.

Löser det problemet att rensa webbläsarens cache? Sällan, och bara när felet ligger på enheten. Är kedjan trasig på servern ändrar cacherensning ingenting för någon.

Hur skiljer det sig från ERR_CERT_COMMON_NAME_INVALID? AUTHORITY_INVALID betyder att utfärdaren inte kan betros. COMMON_NAME_INVALID betyder att utfärdaren är betrodd men att certifikatet utfärdats för ett annat värdnamn än det som besöks.

Kan jag bara klicka förbi varningen? På din egen testserver, ja. På en webbplats som hanterar riktiga data, nej. Att klicka förbi stänger av exakt det skydd som skulle berätta att anslutningen manipulerats.

Kontrollera din kedja innan besökarna gör det

Ett saknat mellancertifikat är osynligt från ditt eget skrivbord och uppenbart för varje ny besökare. Kör en gratis FortifyNet-skanning och se hela din certifikatkedja, protokollstöd, säkerhetsheaders, DNS och e-postautentisering på cirka 60 sekunder. Ingen registrering krävs.

---

Källor: CA/Browser Forum, Ballot SC-081v3; Chrome Root Program Policy; Let's Encrypt, Chains of Trust.