Webzertifikatfehler im Access Server: leeres CA-Bundle beheben

Eine Weblogin-Seite, die sich nicht laden lässt, während DNS korrekt auflöst, ist meist kein DNS-Problem. Nennt das Dienstprotokoll einen leeren Zertifikatsbundle-Pfad oder einen PEM-Parsefehler für Webzertifikat und privaten Schlüssel, dann hat der HTTPS-Listener kein brauchbares Material, und keine Namensauflösung hilft. Die Reparatur liegt in drei Konfigurationsschlüsseln und erfordert nicht, ein einziges VPN-Clientzertifikat neu auszustellen.

Worauf die drei Schlüssel wirklich zeigen

Das eigene Webzertifikat-Set wird durch cs.cert, cs.priv_key und cs.ca_bundle beschrieben. Jeder speichert einen Dateipfad, und alle drei werden vom Webdienst gemeinsam verbraucht. Ein Zertifikat mit dem falschen Schlüssel oder eine Ketten-Datei, die eigentlich das Blattzertifikat ist, scheitert wie ein leerer Wert: Der Listener kann keine Kette bauen, die ein Browser akzeptiert.

Diese Schlüssel gehören zur Admin- und zur Client-Weboberfläche. Sie sind getrennt von der PKI, die Zertifikate an VPN-Clients ausstellt, daher berührt ein Austausch weder Clientprofile noch Serverschlüssel oder Zertifizierungsstelle. Einen Web-TLS-Fehler als Grund zu nehmen, die ganze PKI neu aufzubauen, ist hier der teuerste Fehlgriff.

Eine Unterscheidung spart Zeit: Ein ausdrücklich leerer eigener Wert ist nicht derselbe Zustand wie gar keine Überschreibung. Der erste übergibt dem Parser einen leeren Pfad, genau das sagt die Protokollzeile. Der zweite lässt Access Server auf eigenem Material, deshalb starten manche Hosts nach einem Upgrade sauber und andere nicht.

Warum eine vorhandene Datei trotzdem nicht parst

Der Parser liest die beschrifteten Blöcke in der Datei, nicht den Dateinamen. Ein .crt mit privatem Schlüssel, eine Kette als ein zusammengeführter Block, wo ein einzelnes Zertifikat erwartet wurde, oder eine Datei mit abgeschnittener letzter Zeile werden alle abgelehnt. RFC 7468 definiert diese lesbaren Labels, weil sie das Einzige sind, was dem Leser sagt, welcher Objekttyp folgt.

Prüfen Sie die Objekte, nicht die Endungen. Auf einem Linux-Host beantworten openssl x509 -noout -subject -issuer -in server.pem und openssl pkey -noout -check -in key.pem die beiden wichtigen Fragen, und der Vergleich von Modulus oder öffentlichem Schlüssel beider beweist, dass sie zusammengehören. Halten Sie die Ausgabe des privaten Schlüssels aus Tickets und Chatprotokollen heraus; die Prüfung braucht einen Fingerabdruck, nicht den Schlüssel.

Ein leerer Pfad verdient dasselbe Misstrauen wie eine fehlerhafte Datei, weil beide vage Folgefehler erzeugen. Sagt das Protokoll, der Bundle-Pfad sei leer, lesen Sie den gespeicherten Wert, bevor Sie die Datei debuggen.

Bewusst auf den Rückfallpfad wechseln

Die CLI des Access Server enthält eine Prüfung, die die drei Pfade als Argumente nimmt und meldet, ob das Set brauchbar ist. Die Pfade unten sind Beispiele; ersetzen Sie sie durch die geschützten Orte auf dem Host:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Lesen Sie das Ergebnis, bevor Sie den laufenden Dienst anfassen, und importieren Sie erst dann die Werte und wenden Sie sie über den dokumentierten Vorgang für die installierte Version an. Das offizielle CLI-Tutorial deckt Prüfung, Import in die Konfigurationsdatenbank und den Anwendungsschritt ab, und seine Version zählt mehr als jede Zusammenfassung.

Prüfen Sie den Namen, den Nutzer wirklich eingeben

Ist das eigene Material defekt und ein gültiger eingebauter Rückfallpfad noch vorhanden, besteht die dokumentierte Wiederherstellung darin, die drei eigenen Überschreibungen zu entfernen und Access Server diesen Rückfallpfad nutzen zu lassen. Sichern Sie zuerst Konsolenzugang und eine Kopie der aktuellen Konfiguration, denn der Dienst, den Sie neu starten, bedient die Verwaltungsoberfläche.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Die gesamte Konfigurationsdatenbank zu leeren ist keine Zertifikatsreparatur. Zielen Sie auf diese drei Schlüssel, wenden Sie an und bestätigen Sie, dass die Weboberfläche antwortet. Die selbstsignierten Dateien im Verzeichnis web-ssl sind die Rückfallressource, kein Arbeitsbereich: Überschreiben oder Neuerzeugen kann das einzige funktionierende Material entfernen.

Erwarten Sie, dass der Browser nach dem Eingreifen des Rückfallpfads ein anderes Zertifikat zeigt. Das ist das richtige Ergebnis, und die Antwort ist, es über Ihren vertrauenswürdigen Verwaltungsprozess zu bestätigen, nicht Nutzern beizubringen, jede Warnung wegzuklicken.

Die Wiederherstellung endet erst mit erfolgreicher Anmeldung

Die Wiederherstellung ist nicht fertig, wenn ein TCP-Listener erscheint. Prüfen Sie den DNS-Namen, die Zertifikatsidentität und die Kette für diesen Namen, laden Sie dann Admin- und Client-Weboberfläche und schließen Sie eine Anmeldung ab. Eine Portprüfung belegt nichts davon.

Access Server 3.1 und später können je SNI-Hostname unterschiedliche Webzertifikate ausliefern. Ist das konfiguriert, sind die Standardschlüssel und die hostnamenspezifischen Einträge getrennte Sets, und ein Test über die IP-Adresse zeigt leicht ein anderes Zertifikat als das, welches Nutzer erhalten. Reparieren und prüfen Sie das Set für den fehlgeschlagenen Namen, und wiederholen Sie dann den Anmeldetest, bevor Sie den Vorfall schließen.