Wer interne Server mit einer Windows Active Directory Certificate Services (AD CS) Sub-CA absichert, kennt das Problem: Zertifikat ist installiert, Nginx läuft, aber der Browser zeigt:

„Ihre Verbindung ist nicht privat“ net::ERR_CERT_COMMON_NAME_INVALID

Oder noch schlimmer: HSTS blockiert jede Möglichkeit, die Seite überhaupt zu öffnen.

In diesem Artikel zeige ich Schritt für Schritt:

• warum das passiert
• wie man es sauber analysiert
• wie man ein korrektes SAN-Zertifikat erstellt
• wie man die Windows-SubCA richtig nutzt
• und wie man Nginx korrekt konfiguriert

Praxisbeispiel: Debian 12 + Nginx + interne Windows-SubCA.

---

1. Das eigentliche Problem: CN reicht nicht mehr

Früher war es ausreichend, wenn der Common Name (CN) im Zertifikat mit dem Hostnamen übereinstimmte.

Beispiel:

CN = server001.intern.example.de

Heute prüfen moderne Browser jedoch ausschließlich die Subject Alternative Names (SAN).

Wenn im Zertifikat kein SAN enthalten ist, bekommt man:

net::ERR_CERT_COMMON_NAME_INVALID

Und bei aktivem HSTS gibt es keinen „Trotzdem fortfahren“-Button mehr.

2. Analyse: Was liefert der Server wirklich aus?

Erster Schritt: prüfen, was Nginx tatsächlich ausliefert.

echo | openssl s_client -connect server001.intern.example.de:443 -servername server001.intern.example.de \
| openssl x509 -noout -subject -issuer -ext subjectAltName

Wenn dort steht:

No extensions in certificate

ist klar:

👉 Das Zertifikat enthält kein SAN 👉 Der Browser lehnt es ab

Wichtig: Das ist kein Nginx-Fehler. Das Zertifikat selbst ist unvollständig.

3. Warum Windows-SubCAs oft kein SAN erzeugen

In AD CS hängt das Verhalten vom Zertifikat-Template ab.

Viele interne Templates:

• übernehmen nur den CN
• ignorieren SAN aus der CSR
• erlauben „Supply in the request“ nicht

Das führt dazu, dass zwar ein Zertifikat erstellt wird, aber ohne SAN.

Und genau das verursacht den Browser-Fehler.

4. Neue CSR mit SAN unter Debian 12 erstellen

Der private Key kann weiterverwendet werden.

Konfigurationsdatei erstellen:

cat > vs31deb-pwm-san.conf <<'EOF'
[req]
default_md = sha256
prompt = no
distinguished_name = dn
req_extensions = req_ext

[dn]
C = DE
ST = NRW
L = Musterstadt
O = Example Org
OU = IT
CN = server001.intern.example.de
emailAddress = admin@example.de

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = server001.intern.example.de
EOF

CSR erzeugen:

openssl req -new \
  -key /etc/ssl/private/vs31deb-pwm.key \
  -out vs31deb-pwm-san.csr \
  -config vs31deb-pwm-san.conf

Diese CSR an die Windows-SubCA übergeben.

5. Windows-CA richtig konfigurieren

Damit SAN übernommen wird, muss das Template:

• „Supply in the request“ erlauben oder
• SAN explizit im Template unterstützen

Falls das Template das blockiert, muss ein CA-Admin es anpassen.

Wird SAN nicht akzeptiert, erzeugt die CA zwar ein Zertifikat – aber ohne SAN. Und damit sind wir wieder beim Browser-Fehler.

6. Fullchain korrekt bauen (sehr wichtig!)

Neben SAN ist die zweite große Fehlerquelle:

fehlende Zertifikatskette

Serverzertifikat + SubCA müssen gemeinsam ausgeliefert werden.

Beispiel:

cat server.pem subca.pem > vs31deb-pwm-fullchain.pem

In Nginx:

ssl_certificate     /etc/ssl/certs/vs31deb-pwm-fullchain.pem;
ssl_certificate_key /etc/ssl/private/vs31deb-pwm.key;

Reload:

nginx -t && systemctl reload nginx

7. Erfolgsprüfung

Nach der Installation:

openssl x509 -in vs31deb-pwm-fullchain.pem -noout -ext subjectAltName

Es muss erscheinen:

X509v3 Subject Alternative Name:
    DNS:server001.intern.example.de

Und:

echo | openssl s_client -connect server001.intern.example.de:443 -servername server001.intern.example.de

Am Ende:

Verify return code: 0 (ok)

Erst dann ist TLS wirklich sauber konfiguriert.

8. Typische Stolperfallen

1. Falscher Serverblock in Nginx

Bei mehreren server {}-Blöcken kann Nginx das falsche Zertifikat ausliefern.

2. DNS zeigt auf 127.0.1.1

Wenn getent ahosts nur Loopback zeigt, ist die Namensauflösung lokal falsch.

3. Intermediate fehlt

Fehlt das SubCA-Zertifikat im Fullchain-File, kommt:

unable to verify the first certificate

4. Browser-HSTS-Cache

Selbst nach Korrektur kann HSTS noch blockieren. Dann HSTS-Eintrag im Browser löschen.

9. Fazit

Bei internen Windows-SubCAs sind zwei Dinge entscheidend:

1. Zertifikat muss ein SAN enthalten
2. Server muss die vollständige Zertifikatskette ausliefern

Der Common Name allein reicht heute nicht mehr.

Moderne Browser prüfen kompromisslos – insbesondere bei HSTS.

Wer systematisch mit openssl s_client testet, findet solche Probleme schnell und sauber.