Kort svar

ERR_CERT_COMMON_NAME_INVALID er Chromes fejlkode for en hostname mismatch: domænet i adresselinjen står ikke i certifikatets Subject Alternative Name (SAN). Navnet "common name" er historisk — Chrome holdt op med at bruge CN-feltet i 2017 og kræver nu navnet i SAN. Fixet er at udstede et certifikat hvor det rigtige domæne står i SAN.

Bekræft årsagen

Se hvilke navne certifikatet faktisk dækker:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Står domænet fra adresselinjen ikke på listen, er det forklaringen. Bemærk: hvis et certifikat slet ikke har et SAN-felt (kun et gammelt CN), viser Chrome også denne fejl — selv hvis CN matcher.

De hyppigste udløsere

  • www vs apex — certifikatet dækker det ene men ikke det andet.
  • Et nyt subdomæne taget i brug uden at komme med på certifikatet.
  • Forkert virtuel host — flere domæner på samme IP og manglende SNI, så standardcertifikatet returneres.
  • Gammelt certifikat uden SAN — typisk selvsignerede certifikater lavet med en forældet OpenSSL-kommando.

Sådan retter du det

  1. Udsted et nyt certifikat med alle nødvendige navne i SAN (fx både example.com og www.example.com). Med ACME tilføjer du blot navnene til certifikatets domæneliste.
  2. Installer det med den fulde kæde og reload tjenesten.
  3. Genererer du et selvsigneret certifikat til test, så sæt SAN eksplicit (gamle one-liners gør det ikke):
openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem \
  -days 365 -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Den lille fælde med selvsignerede certifikater

Mange udviklere kender fejlen fra lokale dev-miljøer. Den ældgamle kommando openssl req -x509 -subj "/CN=localhost" uden -addext subjectAltName producerer et certifikat som moderne browsere afviser med præcis denne fejl. Tilføj altid SAN — også for localhost og 127.0.0.1.

Fang manglende navne før brugerne gør

Fejlen rammer ofte lige efter at et nyt subdomæne er gået live. CertControl opdager nye subdomæner via Certificate Transparency og DNS og markerer endpoints hvor certifikatets SAN ikke dækker det navn der serveres — så du fanger mismatchen ved næste scan i stedet for via en supportsag. Det er én af flere TLS handshake-fejl værd at kende — og for hvilke navne et certifikat bør dække, se single-domæne vs wildcard vs SAN.

Ofte stillede spørgsmål

Hvorfor hedder fejlen "common name" når det handler om SAN?

Af historiske årsager. Domænet lå tidligere i Common Name-feltet. Chrome holdt op med at bruge CN i 2017, men fejlkodens navn blev hængende. I praksis betyder den: navnet mangler i SAN.

Kan jeg klikke videre forbi fejlen?

Ofte kan du i Chrome under "Avanceret", men det er en advarsel om at du ikke kan stole på serverens identitet. Ret certifikatet i stedet for at lære brugerne at ignorere advarsler.

Hvorfor får jeg fejlen på et splinternyt Let's Encrypt-certifikat?

Sandsynligvis fordi du forbinder til et navn der ikke kom med da certifikatet blev udstedt — fx apex mens kun www blev medtaget. Genudsted med begge navne i SAN.

Gælder fejlen kun Chrome?

Fejlkoden er Chromes, men alle moderne browsere afviser certifikater hvor navnet ikke er i SAN. Firefox og Safari viser blot en anden ordlyd.

Se platformen Book demo