DNS und SSL: DNS-Einträge, DNSSEC, TLS, Zertifikate und vollständige Checkliste

Beispiele:

• ein gültiges Zertifikat hilft nicht, wenn der A-Eintrag auf einen alten Server zeigt,
• ein korrekter A-Eintrag reicht nicht aus, wenn AAAA den IPv6-Verkehr auf eine nicht funktionierende Maschine leitet,
• die automatische Zertifikatserneuerung funktioniert nicht, wenn der _acme-challenge-Eintrag nicht erstellt werden kann oder Port 80 blockiert ist,
• DNSSEC kann das Vertrauen in DNS-Antworten erhöhen, aber ein fehlerhafter DS-Eintrag kann für die gesamte Domain einen SERVFAIL verursachen,
• ein kurzer TTL behebt keine fehlerhafte Delegierung der Nameserver,
• ein Wildcard-Zertifikat deckt weder die Hauptdomain noch mehrstufige Subdomains ab, wenn diese nicht separat eingetragen wurden.

Im Jahr 2026 sollte die Zertifikatsverwaltung vollständig automatisiert sein. Ab dem 15. März 2026 dürfen öffentliche TLS-Zertifikate vom Typ Subscriber Certificate eine maximale Gültigkeit von 200 Tagen haben. Das Limit sinkt im März 2027 auf 100 Tage und im März 2029 auf 47 Tage. Let's Encrypt stellt standardmäßig weiterhin 90-tägige Zertifikate aus, bietet aber auch kürzere Profile an, und ab Mai 2026 stellt das Profil tlsserver 45-tägige Zertifikate für Nutzer aus, die es bewusst auswählen.

TL;DR: Betreiben Sie mindestens zwei unabhängig voneinander erreichbare autoritative DNS-Server, kontrollieren Sie die A- und AAAA-Einträge, führen Sie DNSSEC nur mit einem sicheren Prozess für die DS-Verwaltung ein, beschränken Sie die Zertifizierungsstellen über CAA, verwenden Sie TLS 1.3 mit TLS 1.2 als kompatiblem Minimum, automatisieren Sie die Ausstellung und Erneuerung von Zertifikaten über ACME und überwachen Sie Ablaufdatum, Zertifikatskette, SNI, HSTS und Validierungsfehler von mehreren Standorten aus.

Die Informationen und Anforderungen wurden am 23. Juli 2026 überprüft.

DNS, SSL und TLS in einer Tabelle

Schicht	Zuständig für	Wichtigste Elemente	Typische Ausfälle
Domain-Registrar	Domaininhaberschaft und Delegierung	Nameserver, Transfersperre, DS	Kontoübernahme, fehlerhafte Delegierung, alter DS
Autoritativer DNS	tatsächliche Zoneneinträge	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	falsche Adresse, fehlender Eintrag, Split-Brain, falsche Signatur
Rekursiver Resolver	Finden und Zwischenspeichern der Antwort	TTL, Cache, DNSSEC-Validierung, DoH/DoT	veraltete Daten im Cache, fehlerhafte Validierung
TCP/QUIC und TLS	sicherer Kanal zum Server	TLS 1.2/1.3, SNI, ALPN, Zertifikat	schwaches Protokoll, fehlerhafte Chain, Hostname-Mismatch
Zertifikat	Bestätigung der Namensidentität	SAN, Issuer, Gültigkeit, Schlüssel, Signatur	Ablauf, fehlender Name, falsches Intermediate
HTTP	Weiterleitung und HTTPS-Richtlinie	301/308, HSTS, Sicherheitsheader	Redirect-Loop, Mixed Content, fehlendes HSTS

Wie funktioniert die Domainauflösung wirklich?

DNS ist ein hierarchisches und verteiltes Namenssystem. Der Resolver erhält nicht die gesamte Antwort von einem einzigen zentralen Server. Vereinfacht gesagt:

1. Browser und Betriebssystem prüfen den lokalen Cache,
2. der rekursive Resolver fragt die Root-Server ab,
3. die Root-Server verweisen auf die Server der entsprechenden Top-Level-Domain, zum Beispiel .pl,
4. der TLD-Server verweist auf die autoritativen Server der Domain,
5. der autoritative Server gibt einen Eintrag zurück, zum Beispiel A, AAAA oder CNAME,
6. die Antwort wird gemäß dem TTL zwischengespeichert.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS garantiert weder, dass der angegebene Server funktionsfähig ist, noch dass die HTTP-Antwort korrekt ausfällt. Es gibt die in der Zone hinterlegten Daten zurück. Das DNS-Monitoring sollte daher mit TCP-, TLS- und HTTP-Tests kombiniert werden.

1. Die wichtigsten DNS-Einträge

A und AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A verweist auf eine IPv4-Adresse,
• AAAA verweist auf eine IPv6-Adresse.

Der AAAA-Eintrag ist keine folgenlose Ergänzung. Wenn er existiert, können IPv6-fähige Clients versuchen, sich genau darüber zu verbinden. Veröffentlichen Sie AAAA erst, wenn Firewall, Routing, Webserver, Zertifikat und ACME-Challenge über IPv6 einwandfrei funktionieren.

Let's Encrypt bevorzugt bei der http-01-Validierung IPv6, wenn die Domain einen AAAA-Eintrag hat. Fehlerhaftes IPv6 kann zu einer fehlgeschlagenen Ausstellung oder Erneuerung des Zertifikats führen, selbst wenn IPv4 korrekt ist.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

Ein CNAME erstellt einen Alias auf einen anderen DNS-Namen. Ein Name mit CNAME sollte nicht gleichzeitig andere reguläre Daten wie A, AAAA oder MX besitzen, da der CNAME angibt, dass sich die eigentlichen Daten unter einem anderen Namen befinden.

Am Zonen-Apex, also example.com, kollidiert ein klassischer CNAME mit den obligatorischen SOA- und NS-Einträgen. Anbieter umgehen dies durch eigene Mechanismen wie ALIAS, ANAME oder Flattening, dabei handelt es sich jedoch nicht um reguläre CNAME-Einträge, die in der Zone übertragen werden.

NS und SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS gibt die autoritativen Nameserver an. Die Delegierung beim Registrar und die NS-Einträge innerhalb der Zone sollten konsistent sein.

SOA enthält administrative Zonendaten, unter anderem die Seriennummer und Parameter, die von den sekundären Servern verwendet werden. Bei manueller Pflege der Zone muss die Seriennummer nach Änderungen erhöht werden.

Bewährte betriebliche Praxis sind mindestens zwei autoritative Server, die in getrennten Netzwerken oder an getrennten Standorten betrieben werden. ICANN empfiehlt mehrere, voneinander getrennte autoritative Server, die idealerweise geografisch und topologisch getrennt sind.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Eine niedrigere Zahl bedeutet eine höhere Priorität. Das Ziel eines MX-Eintrags sollte ein Hostname sein, keine IP-Adresse und kein CNAME.

Ein Wechsel des Webhostings sollte nicht automatisch die E-Mail-Zustellung verändern. Sichern Sie vor einer DNS-Migration die MX-, SPF-, DKIM- und DMARC-Einträge.

TXT

TXT ist ein Textcontainer, der unter anderem für Folgendes verwendet wird:

• SPF,
• DKIM,
• DMARC,
• die Validierung der Domaininhaberschaft,
• ACME dns-01,
• SaaS-Integrationen.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Mehrere TXT-Einträge unter einem Namen können korrekt sein, aber mehrere konkurrierende SPF-Einträge, die mit v=spf1 beginnen, sind ein Designfehler.

CAA

CAA ermöglicht es dem Domaininhaber anzugeben, welche Zertifizierungsstellen Zertifikate für die Domain ausstellen dürfen.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue betrifft reguläre Zertifikate,
• issuewild betrifft Wildcards,
• iodef gibt den Kanal für die Meldung von Richtlinienverstößen an.

CAA ersetzt weder die Absicherung des Kontos beim Registrar noch DNSSEC oder das Certificate-Transparency-Monitoring. Es ist eine zusätzliche Einschränkung für öffentliche CAs. Fehlt CAA, bedeutet das in der Regel, dass jede öffentlich vertrauenswürdige CA nach erfolgreicher Domainvalidierung ein Zertifikat ausstellen kann.

PTR

PTR realisiert Reverse DNS, also die Zuordnung einer IP-Adresse zu einem Namen. Den Eintrag setzt der Inhaber des IP-Bereichs, in der Regel der VPS- oder Hosting-Anbieter. Er ist besonders wichtig für Mailserver.

192.0.2.10 → mail.example.com

Für E-Mail sollte der PTR-Name in der Regel über A oder AAAA wieder auf dieselbe Adresse zurückführen.

HTTPS und SVCB

Die HTTPS- und SVCB-Einträge können dem Client Informationen über die Art der Verbindung zum Dienst, alternative Endpunkte, unterstützte Protokolle sowie vor dem Verbindungsaufbau benötigte Parameter übermitteln.

Konzeptionelles Beispiel:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

Man sollte ipv4hint oder ipv6hint nicht als Ersatz für korrekte Adresseinträge eintragen, ohne das Verhalten der Clients zu verstehen. Das HTTPS RR ist ein Mechanismus zur Optimierung und Signalisierung und keine Reparatur für fehlerhaftes DNS oder TLS.

2. TTL und die „DNS-Propagation“

Der TTL legt fest, wie lange ein Resolver eine Antwort im Cache halten darf. Es gibt keine einzige globale Propagationsuhr. Nach einer Änderung:

• ein Teil der Resolver hat noch die alte Antwort,
• ein Teil fragt den Server sofort ab,
• negative Antworten wie NXDOMAIN können ebenfalls zwischengespeichert werden,
• das lokale Betriebssystem, der Browser, der Provider und die Anwendung können jeweils einen eigenen Cache haben.

Sinnvolle TTL-Werte

Situation	Typischer Wert
stabiler Produktionseintrag	3600-86400 s
Vorbereitung einer Migration	300-600 s
ACME-DNS-01-Eintrag	30-300 s, sofern der Anbieter es zulässt
NS- oder SOA-Eintrag	in der Regel länger
Notfall-Umschaltung	ein niedriger TTL hilft erst, nachdem der frühere Cache abgelaufen ist

Senken Sie den TTL vor einer Migration mindestens um eine alte TTL-Periode im Voraus. Ein Absenken des TTL fünf Minuten vor der Änderung entfernt keine Antworten, die der Resolver bereits für 24 Stunden gespeichert hat.

Erhöhen Sie den TTL nach Abschluss der Migration wieder, um die Anzahl der Anfragen und die Abhängigkeit von kurzfristigen Problemen des autoritativen DNS zu verringern.

3. DNSSEC: Integrität der Antwort, keine Verschlüsselung

DNSSEC fügt eine Authentifizierung der Herkunft von DNS-Daten und einen Integritätsschutz mithilfe digitaler Signaturen hinzu. Es verschlüsselt weder Anfragen noch verbirgt es Domainnamen vor dem Netzbetreiber oder dem Resolver.

Die Vertrauenskette nutzt unter anderem:

• DNSKEY - die öffentlichen Schlüssel der Zone,
• RRSIG - die Signaturen der Eintragssätze,
• DS - den in der übergeordneten Zone gespeicherten Schlüssel-Fingerabdruck,
• NSEC oder NSEC3 - die kryptografische Bestätigung der Nichtexistenz eines Namens oder Typs.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

RFC 9364 legt die Verwendung von DNSSEC zur Authentifizierung der Herkunft von DNS-Daten als aktuelle bewährte Praxis fest.

Das größte Risiko bei DNSSEC

Das häufigste Problem ist nicht das Fehlen von DNSSEC, sondern eine fehlerhafte DNSSEC-Kette. Wenn beim Registrar ein DS-Eintrag verbleibt, der auf einen alten Schlüssel verweist, während der neue DNS-Betreiber die Zone mit einem anderen Schlüssel signiert, geben validierende Resolver einen SERVFAIL zurück.

Eine sichere DNSSEC-Migration erfordert:

1. zu prüfen, wer die Zone signiert,
2. die Methode für die Übertragung oder den Rollover der Schlüssel festzulegen,
3. den korrekten DS in der übergeordneten Domain zu veröffentlichen,
4. den TTL der DNSKEY- und DS-Einträge abzuwarten,
5. erst danach die alten Schlüssel oder die alte Zone zu entfernen,
6. das Testen über validierende Resolver.

Aktivieren Sie DNSSEC nicht, wenn der Anbieter keinen klaren Prozess für die DS-Verwaltung und die Schlüsselrotation bereitstellt.

4. DNSSEC im Vergleich zu DoH und DoT

Diese Mechanismen lösen unterschiedliche Probleme:

Mechanismus	Schützt	Bietet nicht
DNSSEC	Authentizität und Integrität der DNS-Daten	Vertraulichkeit der Anfrage
DNS over TLS	Verschlüsselung zwischen Client und Resolver über TLS, in der Regel Port 853	Authentizität der Daten ohne DNSSEC-Validierung
DNS over HTTPS	Verschlüsselung von DNS in HTTPS	Authentizität der Daten ohne DNSSEC
Einfaches DNS	grundlegende Namensauflösung	Vertraulichkeit und kryptografische Integrität

DNS over TLS beschreibt RFC 7858, DNS over HTTPS RFC 8484. Der verschlüsselte Transport schützt die Anfrage vor einfachem Abhören auf der Strecke Client-Resolver, aber der Betreiber des Resolvers sieht die Anfragen weiterhin, und die weitere Auflösung hängt von seiner Richtlinie ab.

5. SSL und TLS: die korrekte Terminologie

„SSL-Zertifikat“ ist nach wie vor ein verbreiteter Marketingbegriff, aber moderne Websites verwenden TLS. SSL 2.0 und SSL 3.0 sind veraltet, und TLS 1.0 und 1.1 wurden von der IETF formell zurückgezogen.

Im Jahr 2026:

• TLS 1.3 sollte bevorzugt werden,
• TLS 1.2 bleibt das kompatible Minimum für ältere, weiterhin unterstützte Clients,
• TLS 1.0, TLS 1.1, SSLv2 und SSLv3 sollten deaktiviert sein,
• die TLS-1.2-Konfiguration sollte moderne Cipher Suites mit AEAD und Forward Secrecy verwenden,
• der Server sollte keine veralteten Algorithmen und Schlüsselaustauschverfahren anbieten.

RFC 9325 enthält aktuelle Empfehlungen für die sichere Verwendung von TLS und hat das frühere BCP 195 ersetzt.

6. Was prüft der Browser im Zertifikat?

Während einer TLS-Verbindung prüft der Client unter anderem:

1. ob sich das Zertifikat innerhalb des Gültigkeitszeitraums befindet,
2. ob der Hostname im subjectAltName enthalten ist,
3. ob die Signatur über eine korrekte Zwischenkette zu einer vertrauenswürdigen Root-CA führt,
4. ob das Zertifikat nicht für einen unzulässigen Zweck verwendet wird,
5. ob die Verbindungsparameter akzeptabel sind,
6. ob die Browser-Richtlinien das Zertifikat nicht ablehnen.

Die Serveridentität wird heute anhand des SAN verifiziert, nicht anhand des Felds Common Name als primärer Namensquelle.

SAN

Ein einzelnes Zertifikat kann mehrere Namen abdecken:

example.com
www.example.com
api.example.com

Jeder Name muss im SAN enthalten sein.

Wildcard

*.example.com

deckt ab:

www.example.com
api.example.com
shop.example.com

deckt aber nicht automatisch ab:

example.com
www.eu.example.com

Die Hauptdomain muss separat hinzugefügt werden, und ein Wildcard funktioniert nur für eine Label-Ebene.

SNI

Server Name Indication ermöglicht es dem Client, den Hostnamen während des Handshakes zu übermitteln, sodass eine einzige IP-Adresse mehrere Zertifikate bedienen kann. Eine fehlerhafte SNI-Konfiguration führt häufig dazu, dass das Zertifikat einer anderen Domain angezeigt wird.

Zertifikatskette

Der Server sollte das Domain-Zertifikat sowie die benötigten Zwischenzertifikate senden, in der Regel aber nicht das Root-Zertifikat. Ein fehlendes Intermediate kann auf einem Gerät funktionieren, das das Zertifikat zuvor gespeichert hat, und auf einem anderen fehlschlagen.

7. Zertifikatsgültigkeit im Jahr 2026

Das CA/Browser Forum hat einen Zeitplan zur Verkürzung öffentlicher TLS-Zertifikate beschlossen:

Ausstellungsdatum	Maximale Gültigkeit
vor dem 15. März 2026	398 Tage
15. März 2026 - 14. März 2027	200 Tage
15. März 2027 - 14. März 2029	100 Tage
ab dem 15. März 2029	47 Tage

Das bedeutet nicht, dass jede CA ein Zertifikat für den maximalen Zeitraum ausstellt. Let's Encrypt stellt standardmäßig weiterhin 90-tägige Zertifikate aus, bietet optionale sechstägige Zertifikate und das Profil tlsserver mit 45-tägigen Zertifikaten, das seit Mai 2026 für frühe Implementierungen verfügbar ist.

Das Fazit ist einfach: Die manuelle Erneuerung von Zertifikaten ist keine sinnvolle betriebliche Praxis mehr.

8. ACME und die Automatisierung von Zertifikaten

ACME ist ein Standardprotokoll, das die Kontoregistrierung, die Validierung der Domainkontrolle sowie die Ausstellung, Erneuerung und den Widerruf von Zertifikaten automatisiert.

HTTP-01

Die CA ruft eine Datei ab:

http://example.com/.well-known/acme-challenge/TOKEN

Vorteile:

• einfache Konfiguration für einen einzelnen Webserver,
• einfache Automatisierung,
• keine DNS-API erforderlich.

Einschränkungen:

• erfordert einen erreichbaren Port 80,
• stellt keine Wildcards aus,
• die Challenge muss den richtigen Server erreichen,
• ein fehlerhaftes AAAA, ein Proxy, eine Weiterleitung oder ein Load Balancer können die Validierung unterbrechen.

Let's Encrypt empfiehlt, Port 80 für öffentliche Webserver offen zu lassen und den normalen Verkehr auf HTTPS umzuleiten.

DNS-01

Der Client veröffentlicht einen TXT-Eintrag:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Vorteile:

• unterstützt Wildcards,
• funktioniert ohne öffentlichen HTTP-Server,
• eignet sich für die zentrale Verwaltung von Zertifikaten.

Risiken:

• erfordert einen sicheren Zugriff auf die DNS-API,
• Propagation und Cache können die Validierung verzögern,
• ein API-Token mit Bearbeitungsrecht für die gesamte Zone vergrößert die Auswirkungen eines Lecks,
• alte TXT-Einträge können die Diagnose erschweren.

Let's Encrypt empfiehlt ausdrücklich die Verwendung von DNS-01 mit einem Anbieter, der eine API anbietet, da die Automatisierung der Erneuerungen entscheidend ist. Weisen Sie dem Token den kleinstmöglichen Umfang zu: am besten nur für die _acme-challenge-Einträge, nicht für die Verwaltung der Domain, des Kontos oder aller Zonen.

Wildcards bei Let's Encrypt erfordern DNS-01.

TLS-ALPN-01

Die Validierung erfolgt über eine spezielle TLS-Verbindung auf Port 443 und das ALPN-Protokoll. Sie ist nützlich für spezialisierte Proxys und Systeme zur Zertifikatsverwaltung, wird aber seltener manuell konfiguriert.

Renewal Information

Ein moderner ACME-Client sollte ACME Renewal Information, also ARI, unterstützen. Anstatt jedes Zertifikat nach einem einzigen starren Schwellenwert zu erneuern, kann der Client von der CA ein empfohlenes Erneuerungsfenster erhalten. Let's Encrypt empfiehlt, die ARI-Informationen mindestens zweimal täglich abzurufen.

9. CAA und ACME: ein praktisches Beispiel

Für Let's-Encrypt-Zertifikate:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Wenn Sie keine Wildcards möchten:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Vor der Ausstellung ist eine öffentliche CA verpflichtet, CAA zu prüfen. Seit dem 15. März 2026 schreiben die Anforderungen des CA/Browser Forum außerdem eine DNSSEC-Validierung für CAA-bezogene Anfragen vor, die aus der primären Netzwerkperspektive durchgeführt werden, und ein DNSSEC-Validierungsfehler darf nicht als Zustimmung zur Ausstellung gewertet werden.

Denken Sie nach einem Wechsel der CA daran, CAA zu aktualisieren, bevor Sie den neuen Ausstellungsprozess starten.

10. HTTPS, Weiterleitungen und HSTS

Minimales Schema:

http://example.com
        ↓ 301 lub 308
https://example.com

Nach der Bestätigung, dass HTTPS vollständig funktioniert, kann man Folgendes hinzufügen:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS weist den Browser an, künftig ausschließlich HTTPS zu verwenden und das Umgehen bestimmter Zertifikatsfehler nicht zuzulassen.

Beginnen Sie nicht mit einem langen max-age, includeSubDomains und preload, wenn:

• es Subdomains ohne HTTPS gibt,
• ein Teil der Infrastruktur von einem Partner verwaltet wird,
• der Erneuerungsprozess nicht getestet wurde,
• kein Zertifikats-Monitoring vorhanden ist,
• unklar ist, ob der alte Dienst weiterhin benötigt wird.

HSTS-Preload verankert die Regel in der Auslieferung der Browser. Das Entfernen eines Eintrags kann Wochen dauern.

11. Die häufigsten DNS-Fehler

Fehlerhafter AAAA-Eintrag

IPv4 funktioniert, aber ein Teil der Clients wählt ein nicht funktionierendes IPv6. Die Symptome treten je nach Netzwerk des Nutzers zufällig auf.

CNAME und andere Einträge unter demselben Namen

Der Alias kollidiert mit Adress-, MX- oder TXT-Einträgen. Das Panel des Anbieters kann die Änderung blockieren oder eine mehrdeutige Zone erzeugen.

Inkonsistente NS-Delegierung

Der Registrar verweist auf andere Server als die Zone, oder einer der Server hat eine ältere Datenversion.

Alter DS nach einem DNS-Wechsel

Die Domain gibt nur bei Resolvern, die DNSSEC validieren, einen SERVFAIL zurück.

Dauerhaft zu niedriger TTL

Erhöht die Anzahl der Anfragen und die Anfälligkeit gegenüber kurzfristiger DNS-Nichtverfügbarkeit, sorgt aber nicht automatisch für ein schnelles Failover.

Zu hoher TTL vor einer Migration

Alte Adressen bleiben über viele Stunden im Cache.

Zurückgebliebene TXT-Einträge

Alte Verifizierungs- und ACME-Tokens erschweren das Audit und vergrößern das betriebliche Chaos.

Fehlende Konsistenz zwischen www und Apex

example.com und www.example.com verweisen auf unterschiedliche Systeme, haben unterschiedliche Zertifikate oder erzeugen eine Weiterleitungsschleife.

12. Die häufigsten TLS- und Zertifikatsfehler

Zertifikat abgelaufen

Die Ursache ist meist nicht das Fehlen von Automatisierung, sondern ein Automatismus, der ohne Alarm ausgefallen ist.

Zertifikat deckt den Host nicht ab

Ein Zertifikat für example.com sichert nicht automatisch www.example.com ab.

Unvollständige Chain

Es fehlt ein Zwischenzertifikat. Das Problem kann nur auf neuen Geräten oder bei bestimmten Clients auftreten.

Falsches Zertifikat aufgrund von SNI

Der Reverse-Proxy hat einen fehlerhaften Default Virtual Host, oder die neue Domain wurde nicht zum Mapping hinzugefügt.

Alte Protokolle und Cipher Suites

Der Server bietet weiterhin TLS 1.0/1.1 oder alte Cipher Suites an, weil die Konfiguration viele Jahre alt ist.

Fehlende Konsistenz über mehrere Schichten

Das CDN hat ein gültiges öffentliches Zertifikat, aber die Verbindung CDN→Origin ist unverschlüsselt oder überprüft den Hostnamen nicht.

Erneuerung durchgeführt, aber der Prozess hat den Server nicht neu geladen

Die neue Zertifikatsdatei liegt auf der Festplatte, aber Nginx, Apache, HAProxy oder die Anwendung verwenden weiterhin das alte Zertifikat aus dem Speicher.

13. Diagnose Schritt für Schritt

DNS-Einträge

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegierung

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

Ein SERVFAIL, während es ohne Validierung funktioniert, ist ein starkes Signal für ein DNSSEC-Problem.

Zertifikat und SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Zertifikatsdaten

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP und HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Prüfen Sie die Weiterleitung, Strict-Transport-Security, den Hostnamen, den Endstatus und das Fehlen von Schleifen.

Sie können auch den kostenlosen DNS- und SSL-Inspektor von POLPROG verwenden, der DNS-Einträge sowie Informationen zum TLS-Zertifikat anzeigt. Ergänzen Sie den Test durch den Inspektor für Sicherheitsheader, den Website-Gesundheitscheck und den Artikel Grundlagen der Sicherheit von Webanwendungen.

14. Produktions-Monitoring

Überwachen Sie nicht nur die Homepage von einem einzigen Standort aus. Mindestumfang:

• Antwort des autoritativen DNS,
• A-, AAAA-, CNAME-, NS-, MX- und CAA-Einträge,
• DNSSEC-Validierung,
• Erreichbarkeit über IPv4 und IPv6,
• Zertifikatsdaten,
• SAN-Übereinstimmung,
• vollständige Chain,
• TLS 1.2 und TLS 1.3,
• finale HTTP→HTTPS-Weiterleitung,
• HSTS,
• Antwort des Origins hinter dem CDN,
• Funktion von ACME und die letzte erfolgreiche Erneuerung.

Alarmschwellen für Zertifikate

Für ein vollständig automatisches System:

Verbleibende Zeit	Reaktion
30 Tage	Warnung oder Trendkontrolle
14 Tage	Alarm, der eine Analyse erfordert
7 Tage	betrieblicher Vorfall
3 Tage	kritischer Alarm und Eskalation
weniger als 24 h	bevorstehender Ausfall

Die Schwellenwerte sollten an die Laufzeit des Zertifikats angepasst werden. Bei sechstägigen oder 45-tägigen Zertifikaten muss das Monitoring proportional zum Erneuerungszyklus deutlich früher reagieren.

15. Sichere DNS- und TLS-Checkliste

Registrar und DNS

• Das Registrar-Konto hat MFA.
• Der Domaintransfer ist gesperrt.
• Kontaktdaten und Wiederherstellungsprozess sind aktuell.
• Es werden mindestens zwei autoritative DNS-Server verwendet.
• Die Server werden in getrennten Netzwerken oder an getrennten Standorten betrieben.
• Die NS-Delegierung beim Registrar und in der Zone ist konsistent.
• Die A- und AAAA-Einträge verweisen auf aktive Infrastruktur.
• IPv6 wird tatsächlich überwacht.
• Die MX-, SPF-, DKIM- und DMARC-Einträge bleiben bei Migrationen erhalten.
• CAA erlaubt nur die verwendeten CAs.
• Es gibt keine überflüssigen TXT-Einträge und Verifizierungstokens.
• Der TTL wurde vor der Migration rechtzeitig gesenkt.
• Der TTL wurde nach der Stabilisierung wieder erhöht.
• Der Zugriff auf die DNS-API hat minimale Berechtigungen.

DNSSEC

• Der Anbieter unterstützt DNSSEC und die Schlüsselrotation.
• Der DS-Eintrag beim Registrar entspricht dem aktiven DNSKEY.
• Für Wechsel des DNS-Betreibers gibt es einen DNSSEC-Migrationsplan.
• Alte DS und Schlüssel werden erst nach Ablauf des Caches entfernt.
• Die Domain wird über einen validierenden Resolver getestet.
• Ein Alarm erkennt SERVFAIL und den Ablauf der Signaturen.

Zertifikate

• Zertifikate werden über ACME ausgestellt und erneuert.
• Die Erneuerung wurde getestet, nicht nur die erste Ausstellung.
• Der Prozess lädt den Server nach der Installation eines neuen Zertifikats neu.
• Alle Hosts sind im SAN enthalten.
• Wildcards werden bewusst eingesetzt.
• Die Chain enthält die korrekten Intermediates.
• Der private Schlüssel verlässt nicht das zuständige System.
• Die Berechtigungen für den Schlüssel sind eingeschränkt.
• Die Alarme funktionieren unabhängig vom ACME-Client selbst.
• DNS-01 verwendet einen eingeschränkten API-Token.
• HTTP-01 funktioniert über IPv4 und IPv6.
• Eine Staging-CA wird für Automatisierungstests verwendet.

TLS und HTTPS

• TLS 1.3 ist aktiviert.
• TLS 1.2 bleibt nur für die erforderliche Kompatibilität erhalten.
• TLS 1.0, TLS 1.1 und SSL sind deaktiviert.
• Der Server bietet keine veralteten Cipher Suites an.
• SNI liefert für jeden Host das korrekte Zertifikat.
• HTTP leitet direkt zu HTTPS weiter.
• Es gibt keinen Mixed Content.
• HSTS wurde stufenweise eingeführt.
• includeSubDomains ist für die gesamte Domain sicher.
• Preload wurde vor der Anmeldung analysiert.
• CDN→Origin verwendet ebenfalls korrekt verifiziertes TLS.

Fazit

Eine gute DNS- und TLS-Konfiguration im Jahr 2026 beruht auf vier Grundsätzen:

1. DNS muss konsistent und betrieblich widerstandsfähig sein.
2. DNSSEC sollte nur mit einer korrekten Verwaltung von DS und Schlüsseln eingeführt werden.
3. Zertifikate müssen automatisch über ACME verwaltet werden.
4. TLS 1.3, eine korrekte Chain, Monitoring und HSTS sind Teil eines einzigen Prozesses und keine getrennten Aufgaben.

Das größte Risiko ist nicht das Fehlen des „grünen Schlosses“ am Tag der Inbetriebnahme. Es ist der stille Ausfall einige Monate später: ein abgelaufenes Zertifikat, ein veralteter AAAA-Eintrag, ein zurückgebliebener DS, ein DNS-Token mit übermäßigen Berechtigungen oder ein Erneuerungsautomatismus, den niemand überwacht hat.