Läuft das Zertifikat eines Login-, API- oder Patchservers ab oder fehlt ein Zwischenzertifikat, scheitern ab diesem Moment die TLS-Verbindungen aller Clients, die sich neu verbinden.
Warum Zertifikat abgelaufen, Server sendet das Zwischenzertifikat nicht mit, oder Datum und Uhrzeit auf dem Gerät des Spielers sind falsch → Folge Client scheitert an der Zertifikatsprüfung und bricht die TLS-Verbindung ab → Auf dem Bildschirm Kein Login / Endlos-Laden in der Login- oder Patchphase, nur HTTPS-Funktionen wie der Shop schlagen fehl. Bereits verbundene Spieler meist nicht betroffen
Zertifikatsfehler mit eigenem Fehlercode getrennt von anderen Verbindungsfehlern protokollieren und erklären, bei Datumsfehlern zum automatischen Stellen von Datum und Uhrzeit des Geräts auffordern, bei Certificate Pinning Backup-Keys mit einbauen und den Zeitplan für Zertifikatswechsel mit dem Infrastrukturteam abstimmen.
Aufgaben Infrastrukturteam
Netzwerk: Terminiert der Load-Balancer oder das CDN TLS, Status der automatischen Erneuerung verwalteter Zertifikate überwachen und auf die verbleibenden Tage alarmieren (bei ACM DaysToExpiry), DNS-Einträge für die Validierung erhalten. Server/OS: Terminiert der Server TLS, Erneuerung automatisieren und Konfiguration danach neu laden, Kette einschließlich Zwischenzertifikat konfigurieren, Restlaufzeit jeder Login-, API- und Patch-Adresse regelmäßig von außen prüfen und alarmieren.
Größenordnungen
Let’s-Encrypt-Zertifikate gelten 90 Tage, empfohlen wird eine Erneuerung alle 60 Tage. AWS Certificate Manager prüft per DNS validierte Zertifikate 45 Tage vor Ablauf und erneuert sie automatisch. Scheitert die automatische Erneuerung unbemerkt, werden genau zum Ablaufzeitpunkt alle neuen Verbindungen auf einmal blockiert.
Im Graphen
Verbindungen brechen gleichzeitig ab · Erfolgreiche Logins, TLS-Handshake-Fehler
Wo nachsehen
Mit openssl s_client -connect HOST:443 -showcerts die Zertifikatsliste ansehen, die der Server tatsächlich sendet, und das Ablaufdatum (notAfter) jedes Zertifikats mit openssl x509 -noout -enddate prüfen. Terminiert der Load-Balancer TLS: Zahl der TLS-Aushandlungsfehler (bei AWS ALB und NLB ClientTLSNegotiationErrorCount) und erfolgreiche Logins
Spricht dafür
Ablaufdatum überschritten oder Zwischenzertifikat fehlt in der vom Server gesendeten Liste, und der Anstieg der Fehler beginnt zum Ablaufzeitpunkt oder zum Zeitpunkt des Zertifikatswechsels
Spricht dagegen
Zertifikatsliste und Ablaufdatum in Ordnung, nur einige Spieler scheitern: Datum und Uhrzeit auf deren Gerät oder die Root-Zertifikatsliste eines alten OS prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Eine Konfiguration ohne Zwischenzertifikat kann im PC-Browser fehlerfrei wirken. Browser merken sich Zwischenzertifikate von anderen Websites und füllen die Lücke damit. Clients ohne einen solchen Speicher, etwa Android-Apps, scheitern. Auch die Laufzeiten werden kürzer. Let’s Encrypt will die Standardlaufzeit 2027 auf 64 Tage und 2028 auf 45 Tage verkürzen. Eine fest auf 60 Tage eingestellte Erneuerung lässt bei 64-Tage-Zertifikaten nur vier Tage Puffer und überschreitet bei 45-Tage-Zertifikaten den Ablauf. AWS Certificate Manager erneuert importierte Zertifikate nicht automatisch, und werden die DNS-Einträge für die Validierung gelöscht, scheitert die Erneuerung. Ein blockierter Login sieht ähnlich aus wie bei „DNS-Störung oder -Verzögerung“. Bei Zertifikatsproblemen wird die Serveradresse aber gefunden, und der Fehler tritt erst im TLS-Handshake auf. Außerdem fällt der Beginn mit dem Ablaufzeitpunkt oder dem Zeitpunkt des Zertifikatswechsels zusammen.
FAQLet's Encrypt Standardlaufzeit der Zertifikate 90 Tage, Erneuerung alle 60 Tage empfohlen
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Verkürzung der Standardlaufzeit im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage, eine Erneuerung im festen 60-Tage-Abstand reicht dann nicht mehr, empfohlen wird die Erneuerung nach etwa zwei Dritteln der Laufzeit
Renewal for domains validated by DNSAWS 45 Tage vor Ablauf wird geprüft, ob das Zertifikat in AWS-Diensten verwendet wird und der CNAME-Eintrag für die Validierung vorhanden ist, dann folgt die automatische Erneuerung. Gelingt die Validierung nicht, Benachrichtigung 30, 15, 7, 3 und 1 Tag vor Ablauf
Supported CloudWatch metricsAWS DaysToExpiry: verbleibende Tage bis zum Ablauf des Zertifikats, bis zum Ablauf zweimal täglich veröffentlicht
Security with network protocolsAndroid (Google) Sendet der Server das Zwischenzertifikat nicht mit, scheitern Android-Apps mit SSLHandshakeException. PC-Browser ergänzen es womöglich aus gespeicherten Zwischenzertifikaten und zeigen keinen Fehler. Die Kette des Servers mit openssl s_client prüfen
Network security configurationAndroid (Google) Bei Certificate Pinning müssen für Schlüssel- und CA-Wechsel Backup-Keys mit eingebaut werden, sonst scheitern Verbindungen, bis die App aktualisiert ist
openssl-s_clientOpenSSL -showcerts: zeigt die vom Server gesendete Zertifikatsliste in der gesendeten Reihenfolge (keine validierte Kette)
openssl-x509OpenSSL -enddate: gibt das Ablaufdatum (notAfter) aus, -checkend: prüft, ob das Zertifikat innerhalb der angegebenen Sekunden abläuft
CloudWatch metrics for your Application Load BalancerAWS ClientTLSNegotiationErrorCount: Zahl der Verbindungen, bei denen keine TLS-Session zustande kam, etwa weil der Client die Prüfung des Serverzertifikats nicht bestanden und die Verbindung abgebrochen hat