SSL für API-Endpunkte prüfen
api ssl zertifikat · https api tls · ssl fehler api client
API-TLS pragmatisch prüfen: Hostname, Chain, alte Clients, SDK-Fehler, Zertifikatsrotation und Alerting.
Von DN01 Netzwerk-Team
API-Clients melden TLS-Probleme oft kryptischer als Browser und brechen automatisierte Workflows sofort ab. Für Besucher sieht das Ergebnis oft nur wie "Diese Verbindung ist nicht privat" aus, während Betreiber mehrere Schichten auseinanderhalten müssen: DNS-Ziel, Server Name Indication, Zertifikatskette, Gültigkeit, SAN-Namen, Protokollversion und Browser-Cache.
Der praktische Startpunkt ist der DN01 SSL Certificate Checker unter /de/ssl-certificate-checker. Er zeigt die öffentlich sichtbare TLS-Antwort einer Domain und hilft, Panel-Angaben, Load-Balancer-Konfiguration und Browserfehler gegen Live-Daten zu prüfen.
Dieser Leitfaden ist bewusst operativ geschrieben: erst eingrenzen, dann ändern, danach erneut messen. Verlinken Sie die relevanten SSL-Guides im Change-Ticket, damit Support, Hosting-Team und Entwickler nicht mit unterschiedlichen Annahmen arbeiten.
Wann dieser Check wichtig ist
Prüfen Sie API-Endpunkte vor SDK-Releases, Zertifikatsrotationen, Gateway-Wechseln, Partner-Onboarding und wenn nur bestimmte Client-Versionen Fehler zeigen.
Besonders kritisch sind Änderungen, die nicht überall gleichzeitig sichtbar werden: DNS-Umzüge, neue CDN-Zonen, Ingress-Regeln in Kubernetes, Zertifikatswechsel auf mehreren Nodes oder parallele IPv4/IPv6-Pfade. Prüfen Sie deshalb nicht nur die Hauptdomain, sondern auch www, api, mail, staging und jede öffentlich verlinkte Subdomain.
Öffnen Sie /de/ssl-certificate-checker, testen Sie den Hostnamen ohne Pfad und dokumentieren Sie Zeitpunkt, IP-Ziel, Ablaufdatum, Aussteller und Kette. Bei DNS-Fragen ergänzt /de/dns-checker die Sicht auf A-, AAAA- und CNAME-Ziele; bei Security-Headern hilft /de/http-header-checker.
Schritt-für-Schritt prüfen
1. Domain im SSL Checker testen und zuerst den Hostnamen im Zertifikat mit der geprüften Domain vergleichen. 2. notBefore und notAfter lesen. 3. Intermediate-Zertifikate und Reihenfolge prüfen. 4. Ergebnis mit Browserfehler, Server-Config und Deploy-Zeitpunkt abgleichen.
Testen Sie den öffentlichen API-Host im SSL Checker und vergleichen Sie die Daten mit Client-Logs. Achten Sie auf SAN, vollständige Kette und TLS-Versionen, die Ihre Client-Bibliotheken unterstützen.
Wenn ein Ergebnis unerwartet ist, wiederholen Sie die Prüfung mit exakt demselben Hostnamen nach einem TTL-Zyklus und zusätzlich über den alternativen Namen, zum Beispiel example.com und www.example.com. Unterschiedliche Resultate deuten meist auf SNI, CDN, IPv6 oder einen nicht aktualisierten Backend-Knoten hin.
Häufige Fehler in der Praxis
Entwickler testen die Webdomain, obwohl api.example.com ein eigenes Zertifikat hat. Alte Java-Trust-Stores scheitern an CA-Wechseln, obwohl moderne Browser funktionieren.
Ein weiterer Klassiker ist die Verwechslung von Zertifikat und HTTPS-Weiterleitung: Ein Redirect auf https://www.example.com hilft nicht, wenn https://example.com bereits vor dem Redirect mit falschem Zertifikat antwortet. Der TLS-Handshake passiert zuerst, die HTTP-Weiterleitung danach.
Verlassen Sie sich nicht nur auf Hosting-Panels. Panels zeigen oft das gespeicherte Zertifikat, nicht zwingend das Zertifikat, das der öffentliche Edge, Proxy oder Mail-Server gerade ausliefert.
Nützliche Querprüfungen
Lesen Sie im selben Cluster weiter: /de/guides/ssl/tls-12-tls-13-migration, /de/guides/ssl/ssl-chain-unvollstaendig-beheben, /de/guides/ssl/ssl-monitoring-alerts-einrichten. Diese Guides decken angrenzende Ursachen ab und verhindern, dass ein Chain-Problem als DNS-Problem oder ein HSTS-Problem als Zertifikatsproblem behandelt wird.
Für Migrationen lohnt sich ein kleines Prüfprotokoll: alte IP, neue IP, geprüfter Hostname, Zertifikatsfingerprint, Ablaufdatum, Chain-Status, Browserfehler und verantwortlicher Dienst. Dieses Protokoll beschleunigt Eskalationen, weil Provider konkrete Live-Werte statt Screenshots aus lokalen Browsern bekommen.
Nach der Korrektur erneut mit dem SSL Checker prüfen und erst dann Caches, CDN-Purge oder HSTS-Änderungen ausrollen. So bleibt klar, welche Änderung den Fehler wirklich beseitigt hat.
| Beobachtung | Wahrscheinliche Ursache | Nächster Schritt |
|---|---|---|
| Browserfehler nur auf einer Subdomain | SAN-Name fehlt oder falscher vHost | Subdomain separat im SSL Checker prüfen |
| Mobil funktioniert, Desktop nicht | Kette oder Trust Store unterscheidet sich | Intermediate-Reihenfolge vergleichen |
| IPv6 liefert anderes Zertifikat | AAAA-Pfad zeigt auf alten Edge | DNS und Load Balancer gemeinsam prüfen |
| Fehler nach Renewal | Neues Zertifikat nicht auf allen Nodes aktiv | Fingerprint pro Edge/Backend vergleichen |
Häufig gestellte Fragen
- Warum funktioniert curl, aber die App nicht?
Unterschiedliche Trust Stores, TLS-Versionen oder SNI-Unterstützung können das erklären.
- Soll jede API überwacht werden?
Ja, besonders externe Partner- und Zahlungs-Endpunkte brauchen Ablauf- und Chain-Alerts.