Certifikatet är äkta och giltigt, men det utfärdades för andra namn än det du ser i adressfältet. Så här uppstår ERR_CERT_COMMON_NAME_INVALID och så åtgärdar både besökare och webbplatsägare felet.

ERR_CERT_COMMON_NAME_INVALID: vad felet betyder och hur du åtgärdar det

ERR_CERT_COMMON_NAME_INVALID betyder att webbplatsen visade upp ett äkta certifikat som inte har gått ut, men certifikatet utfärdades för ett annat namn än det som står i ditt adressfält. Chrome jämför domänen du begärde med värdnamnen i certifikatets SAN-fält (Subject Alternative Name). Om inget av dem stämmer blockerar Chrome sidan med det här felet. Åtgärden beror på vem du är: som besökare kan du oftast lösa eller bedöma situationen på några minuter, medan du som webbplatsägare behöver utfärda om eller konfigurera om ett certifikat. Den här guiden täcker båda, med data om hur vanlig varje orsak faktiskt är.

Vad felet egentligen betyder

Varje publikt HTTPS-certifikat innehåller en lista över värdnamn det gäller för, lagrad i SAN-tillägget. Historiskt accepterade webbläsare även certifikatets Common Name-fält (CN), och det är därifrån felet fått sitt namn. Den reservlösningen är sedan länge borta:

RFC 2818 avrådde från CN-matchning för HTTPS redan år 2000.
Chrome 58 tog bort CN-matchningen helt i april 2017 och har krävt SAN-poster sedan dess (källa: Chrome for Developers, "Deprecations and Removals in Chrome 58"). Vid den tidpunkten förlitade sig bara cirka 0,1 % av alla certifikatvalideringar på CN-reserven (Chromium security-dev, 2017).
RFC 9525 (november 2023), som ersatte RFC 6125, gjorde det formellt i hela branschen: klienter ska enbart kontrollera SAN-tillägget och får inte matcha domännamn mot CN.

Trots namnet betyder felet alltså egentligen "SAN-mismatch": inget i certifikatets namnlista täcker värden du bad om.

Felet är dessutom anmärkningsvärt vanligt. I Googles studie av över 300 miljoner verkliga certifikatvarningar i Chrome (Acer m.fl., "Where the Wild Warnings Are", ACM CCS 2017) var namnmatchningsfel den enskilt största serverorsaken till certifikatvarningar på desktop: 11,7 % av alla varningsrapporter på Windows och 11,6 % på Mac, före ej betrodda utfärdare och utgångna certifikat.

Stapeldiagram över serverorsaker till certifikatvarningar i Chrome på Windows: namn matchar inte 11,7 procent, ej betrodd utfärdare 6,11 procent, utgånget eller fel datum 4,23 procent, saknade mellancertifikat 1,26 procent

Serverorsaker till Chromes certifikatvarningar som andel av alla varningsrapporter på Windows. Data: Acer m.fl., "Where the Wild Warnings Are", ACM CCS 2017.

De 7 vanliga orsakerna, och vem som kan åtgärda dem

#	Orsak	Vad som händer	Vem åtgärdar
1	www-mismatch	Certifikatet täcker `www.example.com` men inte `example.com`, eller tvärtom	Webbplatsägaren
2	Underdomän utanför wildcard-täckning	`*.example.com` täcker inte `app.eu.example.com`	Webbplatsägaren
3	Fel eller standardcertifikat på servern	Delat webbhotell eller en felkonfigurerad server (SNI) svarar med en annan webbplats certifikat	Webbplatsägaren
4	Gammal DNS eller flyttad domän	Domänen pekar fortfarande på en server som inte längre hostar den, så någon annans certifikat svarar	Webbplatsägaren
5	Certifikat med enbart CN	Ett äldre eller internt certifikat har rätt CN men inga SAN-poster; Chrome har avvisat dessa sedan version 58 (april 2017)	Webbplatsägaren / IT
6	Captive portal	Wi-Fi på hotell eller flygplats fångar din första begäran för att visa sin inloggningssida	Besökaren
7	HTTPS-inspektion	Antivirus eller en företagsproxy signerar om trafiken med sitt eget certifikat	Besökaren / IT

Bland namnmatchningsfelen sticker underdomänmisstagen ut. I samma Google-dataset var 13,2 % av serverns namnmatchningsfel begäranden om underdomäner utanför ett wildcards täckning, och 3,7 % var rena www-mismatchar (Acer m.fl., CCS 2017). Ytterligare 3,8 % av namnmatchningsfelen matchade kända captive portal-mönster, vilket betyder att nätverket, inte webbplatsen, orsakade dem.

Om du är besökare: 5 snabba kontroller

Prova adressens andra form. Om example.com inte fungerar, prova www.example.com, eller tvärtom. Fungerar den ena har webbplatsen en www-mismatch och du kan berätta exakt det för ägaren.
Titta på vem certifikatet utfärdades till. Klicka på hänglåset eller "Inte säker", öppna certifikatdetaljerna och läs SAN-listan. Ett certifikat för ett webbhotells platshållardomän eller en helt orelaterad sajt förklarar blockeringen direkt.
På publikt Wi-Fi: utlös inloggningssidan först. Captive portals fångar din första HTTPS-begäran och svarar med sitt eget certifikat. Öppna valfri ren HTTP-sida (till exempel en routers statussida eller neverssl.com), slutför portalinloggningen och försök igen.
Testa med HTTPS-inspektion avstängd. Vissa antivirusprogram och företagsproxyer signerar om TLS-trafik. Stäng tillfälligt av HTTPS-skanningen eller prova ett annat nätverk; försvinner felet är det inspektionsprogramvaran som är orsaken.
Klicka inte vidare på webbplatser som betyder något. För bank, e-post eller allt med inloggning ska en namnmismatch vara ett hårt stopp. Den generella versionen av varningen täcker vi i guiden om felet "Din anslutning är inte privat".

Om du äger webbplatsen: diagnostisera, åtgärda sedan

Laptopskärm som visar övervakningsgrafer och webbplatsstatistik

Börja med att läsa exakt vilka namn ditt certifikat täcker. Från valfri terminal med OpenSSL installerat:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Kör kommandot två gånger, en gång med din apexdomän och en gång med www, och jämför SAN-utdatan med varje värdnamn dina användare faktiskt besöker. Åtgärda sedan orsaken du hittar:

Täck apex och www tillsammans. Utfärda ett certifikat som listar båda namnen. Let's Encrypt inkluderar upp till 100 värdnamn per certifikat utan kostnad (Let's Encrypts dokumentation om gränser), och alla kommersiella CA:er säljer multidomäncertifikat (SAN).
Håll koll på wildcard-täckningen. Ett wildcard matchar exakt en nivå, enligt RFC 9525:

Begärt namn	Täcks av `*.example.com`?
`app.example.com`	Ja
`example.com`	Nej, apexdomänen behöver en egen SAN-post
`eu.app.example.com`	Nej, wildcards matchar bara en nivå
`app.example.net`	Nej, annan domän

Fixa SNI och standardvärden. Om din server hostar flera webbplatser, se till att varje värdnamn är kopplat till sitt eget certifikat och att standardvärden (fallback) inte svarar med fel certifikat för klienter eller robotar som utelämnar SNI.
Kontrollera CDN:ets båda ändar. Med ett CDN eller en omvänd proxy framför måste edge-certifikatet täcka ditt publika värdnamn och origin-certifikatet täcka värdnamnet som CDN:et ansluter till. En mismatch i något av leden utlöser fel.
Lita inte på omdirigeringar. TLS förhandlas innan någon HTTP-omdirigering skickas. Även om example.com direkt omdirigerar till www.example.com måste certifikatet som serveras på example.com fortfarande täcka det namnet.

Ett skäl till att automatisera: enligt CA/Browser Forums beslut SC-081v3 (antaget i april 2025) sänktes den maximala livslängden för publika certifikat från 398 till 200 dagar den 15 mars 2026, sänks till 100 dagar i mars 2027 och landar på 47 dagar i mars 2029. Förnyelser blir mycket tätare, och varje förnyelse är en ny chans för en SAN-lista att tyst tappa ett namn. Använd ACME-automation och övervaka täckningen i stället för att lita på minnet.

Vanliga frågor

Är det säkert att klicka på "Fortsätt ändå"? Bara när du säkert vet varför mismatchen finns, till exempel din egen testserver som nås via IP-adress. På webbplatser där du skulle ange lösenord eller betalningsuppgifter: fortsätt inte.

Betyder felet att webbplatsen är hackad? Nästan aldrig. Det betyder oftast ett konfigurationsmisstag: en omdöpt domän, en bortglömd www-post eller ett wildcard som inte räcker så långt som ägaren trodde. Attacker förekommer, och det är precis därför webbläsare vägrar gissa.

Varför heter det "common name" om webbläsare ignorerar CN-fältet? Namnet är historiskt. Webbläsare matchade CN-fältet tills RFC 2818 (2000) avrådde från det och Chrome 58 (april 2017) tog bort det. I dag räknas bara SAN-listan, enligt RFC 9525 (november 2023), men felkoden döptes aldrig om.

Behöver jag ett separat certifikat för varje underdomän? Nej. Ett certifikat kan lista många SAN-poster, och ett wildcard täcker alla direkta underdomäner på en nivå. Extra planering behövs bara för djupare nivåer som a.b.example.com, som ett wildcard på en nivå inte täcker.

Kontrollera certifikatets täckning på 60 sekunder

En namnmismatch är osynlig tills någon träffar just det värdnamn du glömde. FortifyNets gratisskanning läser ditt aktiva certifikat och rapporterar vilka namn det täcker, tillsammans med din TLS-konfiguration, säkerhetsheaders, DNS, e-postautentisering och exponering på dark web. Kör gratisskanningen på din domän och kontrollera apex, www och underdomäner i ett svep.