So sieht die Meldung aus
NET::ERR_CERT_COMMON_NAME_INVALID – This server could not prove that it is www.example.com; its security certificate is from example.com.Häufige Ursachen
- Zertifikat nur für example.com, aufgerufen wird www.example.com (oder umgekehrt).
- nginx liefert das Zertifikat eines anderen vHosts, weil kein
server_namepasst und derdefault_servergreift. - Neue Subdomain angelegt, Zertifikat aber nicht erweitert.
- Zugriff per IP-Adresse oder internem Hostnamen.
- DNS zeigt auf einen anderen Server, z. B. alter Hoster oder CDN ohne passendes Zertifikat.
Prüfen
- Gelieferte Namen im Zertifikat (SAN) anzeigen
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName - Vorhandene Let's-Encrypt-Zertifikate und ihre Domains anzeigen
certbot certificates 2>/dev/null | grep -E 'Certificate Name|Domains' - server_name, Zertifikatspfade und default_server anzeigen
nginx -T 2>/dev/null | grep -nE '^\s*(server_name|ssl_certificate|listen .*default_server)' - Prüfen, ob beide Namen auf denselben Server zeigen
dig +short A www.example.com; dig +short A example.com
Lösung
- Zertifikat um den fehlenden Namen erweitern:
certbot --nginx --expand -d example.com -d www.example.com. - Für jeden Namen einen passenden
server_namemit dem richtigenssl_certificateanlegen. - Einen eigenen
default_servermit Dummy-Zertifikat undreturn 444;einrichten, damit falsche Namen nicht die Kundenseite treffen. - DNS prüfen, wenn das Zertifikat von einem fremden Server stammt.
- Nach Änderungen
nginx -t && systemctl reload nginx.
Häufige Fragen
Reicht der Common Name (CN) im Zertifikat?
Nein. Moderne Browser ignorieren den CN und prüfen nur die SAN-Liste. Selbst erstellte Zertifikate brauchen deshalb ein subjectAltName.
Deckt ein Wildcard-Zertifikat auch die Hauptdomain ab?
Nein. *.example.com gilt für www.example.com, aber nicht für example.com selbst und nicht für a.b.example.com. Die Hauptdomain muss zusätzlich drinstehen.