Kort svar

En hostname mismatch betyder at det domæne du forbinder til ikke står i certifikatets Subject Alternative Name (SAN)-liste. Moderne klienter ignorerer det gamle Common Name (CN)-felt fuldstændigt og validerer kun mod SAN. Hvis certifikatet er udstedt til www.example.com men brugeren går til example.com (eller omvendt), fejler valideringen — selvom certifikatet ellers er helt gyldigt.

Bekræft hvilke navne certifikatet 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"

Outputtet viser fx DNS:www.example.com. Er det domæne du besøger ikke på listen, er det årsagen til fejlen.

De typiske årsager

  • www vs apex: Certifikatet dækker www.example.com men ikke example.com. Løsning: udsted et certifikat med begge navne i SAN, eller redirect det ene til det andet.
  • Forkert certifikat på en multi-domæne-server: Klienten sendte ikke SNI, så serveren returnerede standardcertifikatet for et andet domæne. Se SNI-afsnittet i handshake-guiden.
  • Wildcard-grænse: *.example.com dækker ét niveau — altså api.example.com, men ikke example.com selv og heller ikke a.b.example.com.
  • IP-adresse i stedet for navn: Du forbinder til https://203.0.113.10 mens certifikatet kun har DNS-navne.

SAN vs CN: hvorfor det gamle felt er dødt

Tidligere blev domænet lagt i certifikatets Common Name. Siden 2017 ignorerer browsere CN og kræver at alle gyldige navne står i SAN-feltet. Et certifikat uden SAN — uanset hvad CN siger — vil derfor fejle i moderne klienter. Det er også derfor selvsignerede certifikater genereret med gamle one-liners ofte fejler: de mangler SAN.

Sådan retter du det

  1. Tilføj det manglende navn til SAN ved at udstede et nyt certifikat. Med ACME tilføjer du blot domænet til certifikatets navneliste.
  2. Eller brug et wildcard hvis du har mange subdomæner — men vær opmærksom på wildcard-risici.
  3. Eller redirect apex til www (eller omvendt) på server-niveau, så brugerne aldrig rammer det navn certifikatet ikke dækker.

Genererer du et selvsigneret certifikat til test, så husk eksplicit at sætte SAN:

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem \
  -days 365 -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:dev.local,IP:127.0.0.1"

Undgå mismatch i drift

Hostname mismatch opstår ofte når et nyt subdomæne tages i brug, men ikke kommer med på certifikatet. CertControl scanner jeres domæner, opdager nye subdomæner via Certificate Transparency og DNS, og markerer endpoints hvor certifikatets SAN ikke dækker det navn der faktisk serveres — før jeres brugere ser advarslen.

Ofte stillede spørgsmål

Dækker et www-certifikat også domænet uden www?

Nej, ikke automatisk. www.example.com og example.com er to forskellige navne. Begge skal stå i SAN, ellers fejler det ene. Mange udsteder derfor altid begge navne sammen.

Dækker et wildcard *.example.com selve example.com?

Nej. Et wildcard dækker ét niveau af subdomæner, fx api.example.com, men ikke apex-domænet example.com og heller ikke a.b.example.com.

Hvorfor ignorerer browseren Common Name?

Siden 2017 kræver browsere at gyldige navne står i Subject Alternative Name-feltet. CN bevares kun af historiske årsager og bruges ikke længere til validering.

Kan jeg få et certifikat til en IP-adresse?

Det er muligt med IP i SAN, men de fleste offentlige CA'er udsteder ikke til private IP'er. Til interne IP-adresser bruger man typisk en intern CA.

Se platformen Book demo