Zertifikatfehler der CipherTrust Manager-Webschnittstelle

Veröffentlicht: April 2023. Aktualisiert: August 2026. Geprüft vom Key Management Advisory Team von Encryption Consulting.

Eine CipherTrust Manager- Bereitstellung dient als Steuerungsebene für die Verschlüsselungsschlüssel einer Organisation. Daher erregt eine Browserwarnung auf der zugehörigen Weboberfläche schnell Aufmerksamkeit. Dieser Leitfaden erläutert die Ursachen des Zertifikatfehlers auf der CipherTrust Manager-Weboberfläche, dessen Behebung und wie Sie die Behebung dauerhaft optimieren können, indem Sie diesem Zertifikat denselben Lebenszyklus widmen wie jedem anderen Zertifikat, das eine administrative Schnittstelle schützt.

Was verursacht den Zertifikatsfehler der CipherTrust Manager-Weboberfläche?

Der Fehler liegt in der fehlgeschlagenen TLS-Vertrauensprüfung Ihres Browsers und nicht in einer Fehlfunktion des CipherTrust Managers. Jeder CipherTrust Manager-Knoten wird mit einem Zertifikat für seine Weboberfläche ausgeliefert. Dieses Zertifikat wird standardmäßig automatisch generiert und von der lokalen Zertifizierungsstelle (CA) des Geräts signiert (in der Benutzeroberfläche üblicherweise als KeySecure-Root-CA bezeichnet). Browser vertrauen dieser lokalen CA standardmäßig nicht. Daher wird beim ersten Anmelden an einem neuen Knoten in der Regel eine Zertifikatswarnung angezeigt, obwohl keine Fehlermeldung vorliegt. Dieselbe Warnung erscheint aus einem anderen Grund, sobald ein Unternehmen das Standardzertifikat durch ein Zertifikat einer externen oder unternehmensweiten CA ersetzt: Ist der Upload unvollständig, falsch konfiguriert, abgelaufen oder für den falschen Hostnamen ausgestellt, lehnt der Browser ihn aus einem spezifischen, nachvollziehbaren Grund ab.

Häufige Ursachen für Zertifikatsfehler in der CipherTrust Manager-Weboberfläche

Vier Ursachen sind für die meisten Fälle verantwortlich. Jede Ursache entspricht einem eindeutigen Browser-Fehlercode, was der schnellste Weg ist, sie zu unterscheiden, bevor Sie mit der Fehlersuche beginnen.

Nicht vertrauenswürdige oder selbstsignierte Zertifizierungsstelle (NET::ERR_CERT_AUTHORITY_INVALID)

Das Zertifikat ist gültig und nicht abgelaufen, aber der Browser oder das Betriebssystem vertraut der Zertifizierungsstelle, die es signiert hat, nicht. Dies ist der Standardzustand für einen neuen CipherTrust Manager-Knoten und tritt auch auf, wenn das Stamm- oder Zwischenzertifikat einer externen Zertifizierungsstelle nie der Liste der vertrauenswürdigen externen Zertifizierungsstellen der Schnittstelle hinzugefügt wurde.

Abgelaufenes oder noch ungültiges Zertifikat (NET::ERR_CERT_DATE_INVALID)

Dies kann auf zwei Arten auftreten: Entweder ist das Zertifikat tatsächlich abgelaufen, ohne erneuert worden zu sein, oder die Systemuhr des CipherTrust Manager-Knotens ist nicht mehr mit dem NTP-Protokoll synchronisiert. Die Zertifikatsausstellungslogik von Thales korrigiert das Datum im Feld „notBefore“ um etwa 24 Stunden zurück, um geringfügige Zeitzonen- und Uhrzeitunterschiede zwischen den Knoten auszugleichen. Daher deuten anhaltende Datumsfehler fast immer auf ein NTP-Problem und nicht auf das Zertifikat selbst hin.

Hostname stimmt nicht überein (NET::ERR_CERT_COMMON_NAME_INVALID)

Der allgemeine Name (Common Name) oder der alternative Antragstellername (Subject Alternative Name) des Zertifikats stimmt nicht mit dem im Browser eingegebenen Hostnamen oder der IP-Adresse überein. Dies tritt häufig auf, nachdem ein Knoten umbenannt, ihm eine neue IP-Adresse zugewiesen oder er einem Cluster hinzugefügt wurde, oder wenn ein Zertifikat für einen Load-Balancing-Hostnamen angefordert wurde, über den auch direkt auf einzelne Knoten zugegriffen wird.

Zertifikat hochgeladen, aber noch nicht aktiv

Unmittelbar nach dem Hochladen eines neuen Zertifikats und dem Neustart des Webdienstes kann der Browser noch einige Minuten lang die alte Warnung anzeigen. Erfahrungsgemäß liegt dies fast immer am Zertifikatscache des Browsers oder am noch nicht abgeschlossenen Neustart des Dienstes und nicht an einer systembedingten Verzögerung des CipherTrust Managers selbst, da die Dokumentation von Thales besagt, dass neu ausgestellte Zertifikate sofort aktiv sind. Ein vollständiges Neuladen der Seite oder das Öffnen eines privaten Browserfensters nach dem Neustart behebt das Problem in der Regel.

So beheben Sie den Zertifikatsfehler in der CipherTrust Manager-Weboberfläche

Die folgenden Schritte ersetzen das standardmäßige, vom Browser nicht als vertrauenswürdig eingestufte Zertifikat durch ein von einer externen oder unternehmensinternen Zertifizierungsstelle signiertes Zertifikat. In diesem Beispiel wird ein Zertifikat für einen Knoten mit dem Namen thales01.ec.com konfiguriert; ersetzen Sie die Platzhalter durch Ihren eigenen Hostnamen.

1. Melden Sie sich bei CipherTrust Manager an. Klicken Sie im Dashboard unter CA auf CSR-Tool.

   

2. Klicken Sie auf + CSR erstellen und geben Sie die erforderlichen Informationen ein, einschließlich eines allgemeinen Namens, der genau mit dem Hostnamen übereinstimmt (sowie alternativer Subjektname für alle zusätzlichen DNS-Namen oder IPs), die Sie verwenden werden, um diesen Knoten zu erreichen.

   

3. Überprüfen Sie die Angaben und klicken Sie auf Erstellen.

4. Bewahren Sie den privaten Schlüssel und die CSR auf. Für maximale Sicherheit empfiehlt Thales, die CSR vollständig außerhalb des CipherTrust Managers zu generieren, damit der private Schlüssel niemals dem Gerät zugänglich gemacht wird. Das integrierte CSR-Tool ist für die meisten Implementierungen der einfachere Weg.

   

5. Senden Sie den CSR an Ihre Zertifizierungsstelle, um das signierte Zertifikat zu erstellen.

   Hinweis: Das bevorzugte Zertifikatsformat ist PEM. PKCS12 wird ebenfalls für die kombinierte Zertifikatskette und den privaten Schlüssel unterstützt.

6. Laden Sie die Stamm- und Zwischenzertifikate der Zertifizierungsstelle hoch. Klicken Sie im Dashboard unter dem Abschnitt „Zertifizierungsstelle“ auf „Extern“.

   

7. Klicken Sie auf + Externe Zertifizierungsstelle hinzufügen.

   

8. Geben Sie einen Anzeigenamen ein, fügen Sie das Stammzertifikat der Zertifizierungsstelle in das Feld ein und klicken Sie anschließend auf Speichern.

   

9. Wiederholen Sie die gleichen Schritte, um die Zwischen- oder ausstellende Zertifizierungsstelle hinzuzufügen.

10. Navigieren Sie unter „Admin-Einstellungen“ zu „Schnittstellen“.

    

11. Klicken Sie auf das Dreipunkt-Menü neben Web und wählen Sie Bearbeiten.

    

12. Deaktivieren Sie unter „Automatische Serverzertifikatgenerierung“ die automatische Generierung durch die lokale Zertifizierungsstelle. Dieser Schritt ist wichtiger als er scheint: Wenn Sie ihn überspringen, kann CipherTrust Manager beim nächsten Neustart des Webdienstes ein selbstsigniertes Zertifikat neu generieren und den Rest dieses Prozesses unbemerkt rückgängig machen.

    

13. Fügen Sie die Stammzertifizierungsstelle und die Zwischenzertifizierungsstelle der Liste der externen vertrauenswürdigen Zertifizierungsstellen für diese Schnittstelle hinzu.

    

14. Erweitern Sie die Option „Zertifikat hochladen“ und fügen Sie die vollständige Zertifikatskette (Endzertifikat, gefolgt von Zwischenzertifikat und Stammzertifikat) in das Feld ein.
15. Wählen Sie PEM als Format.
16. Geben Sie das Passwort für den privaten Schlüssel ein, falls während der CSR-Generierung ein solches festgelegt wurde.
17. Klicken Sie auf „Neues Zertifikat hochladen“. Das extern signierte Zertifikat ist nun der Weboberfläche zugewiesen.
18. Navigieren Sie unter Administratoreinstellungen zu Dienste.

19. Klicken Sie auf „Systemneustart“, um die Änderung anzuwenden.

    

20. Sobald die Dienste neu gestartet wurden, rufen Sie den Hostnamen des CipherTrust Managers auf. Sollte weiterhin ein Zertifikatsfehler auftreten, warten Sie einige Minuten, bis der Neustart vollständig abgeschlossen und der Zertifikatscache des Clients geleert ist. Aktualisieren Sie anschließend die Seite, bevor Sie mit der weiteren Fehlerbehebung fortfahren.

Bei einer geclusterten CipherTrust Manager-Bereitstellung muss dieser Vorgang auf jedem Knoten einzeln wiederholt werden. Schnittstellenzertifikate werden pro Knoten konfiguriert und nicht automatisch im gesamten Cluster repliziert, genauso wie Sicherungsschlüssel nicht automatisch zwischen den Knoten ausgetauscht werden, wie in unserem Leitfaden zu Sicherungsfehlern von CipherTrust Manager beschrieben.

Entscheidungstabelle: Symptom, Ursache und Lösung

Symptom	Wahrscheinliche Ursache	Fixieren
NET::ERR_CERT_AUTHORITY_INVALID- oder „Nicht vertrauenswürdig“-Warnung	Das Zertifikat wurde von der standardmäßigen lokalen Zertifizierungsstelle signiert, oder die externe Zertifizierungsstellenkette wurde nie zu den externen vertrauenswürdigen Zertifizierungsstellen hinzugefügt.	Fügen Sie die Stamm- und Zwischenzertifizierungsstelle zu den externen vertrauenswürdigen Zertifizierungsstellen hinzu oder ersetzen Sie das Standardzertifikat durch ein extern signiertes Zertifikat.
NET :: ERR_CERT_DATE_INVALID	Das Zertifikat ist tatsächlich abgelaufen, oder die Uhrzeit des CipherTrust Manager-Knotens weicht vom NTP-Takt ab.	Überprüfen Sie die Gültigkeitsdaten des Zertifikats in der Benutzeroberfläche; korrigieren Sie zuerst die NTP-Synchronisierung und erneuern Sie das Zertifikat nur, wenn es tatsächlich abgelaufen ist.
NET :: ERR_CERT_COMMON_NAME_INVALID	Der CN oder SAN des Zertifikats stimmt nicht mit dem Hostnamen oder der IP-Adresse überein, die zum Erreichen der Schnittstelle verwendet wird.	Stellen Sie das Zertifikat mit den korrekten CN- und SAN-Einträgen für jeden Hostnamen und jede IP-Adresse, über die auf den Knoten zugegriffen wird, neu aus.
Die Warnung erscheint direkt nach einem erfolgreichen Upload und Neustart erneut.	Die automatische Zertifikatsgenerierung von der lokalen Zertifizierungsstelle blieb aktiviert und wurde beim Neustart erneut ausgelöst, oder der Browser speicherte das alte Zertifikat im Cache.	Deaktivieren Sie die automatische Serverzertifikatsgenerierung vor dem Hochladen; starten Sie den Dienst neu; leeren Sie den Zertifikatscache des Browsers oder verwenden Sie ein privates Fenster
Der Fehler ist auf jedem Knoten in einem Cluster identisch.	Das Zertifikat wurde nur auf einen Knoten hochgeladen; Schnittstellenzertifikate werden nicht im gesamten Cluster repliziert.	Wiederholen Sie die Schritte zur CSR-Generierung und zum Hochladen einzeln auf jedem Knoten.

Lebenszyklus-Besitz des Web-Interface-Zertifikats

Da CipherTrust Manager die Steuerungsebene für Verschlüsselungsschlüssel darstellt, verdient sein Webinterface-Zertifikat dasselbe Eigentumsmodell wie ein Zertifikat zum Schutz einer privilegierten Verwaltungskonsole. In der Praxis bedeutet dies, dass ein bestimmtes Team – üblicherweise die Schlüsselverwaltung oder die PKI-Betriebsgruppe und nicht der allgemeine IT-Helpdesk – auf jedem Knoten und Cluster der Organisation als Eigentümer dieses Zertifikats benannt wird. Dieser Eigentümer ist verantwortlich für die Überwachung des Ausstellers, des Ablaufdatums und der Hostnamenabdeckung des Zertifikats; für die rechtzeitige Erneuerung vor Ablauf anstatt auf Browserwarnungen zu reagieren; und für die Aufbewahrung des CSR, des signierten Zertifikats und der CA-Kette am selben Ort mit Änderungsmanagement wie andere produktive TLS-Materialien. Wird dieses Zertifikat als nicht verwaltetes, einmaliges Einrichtungsartefakt behandelt, führt dies genau dazu, dass Organisationen es über eine gesperrte Verwaltungskonsole wiederfinden.

Rotationsauslöser für dieses Zertifikat

CipherTrust Manager protokolliert selbst Ablaufwarnungen 91, 7 und 0 Tage vor Ablauf eines Zertifikats. Dies ist ein sinnvoller Ausgangspunkt für einen Rotationskalender. Zusätzlich zum regulären Ablauf sollte das Webinterface-Zertifikat immer dann rotiert werden, wenn einer der folgenden Fälle eintritt:

• Das Zertifikat nähert sich einem der von CipherTrust Manager intern überwachten Ablaufzeitschwellen von 91, 7 oder 0 Tagen.
• Die ausstellende Zertifizierungsstelle ist kompromittiert, wird von Browser-Vertrauensspeichern als veraltet eingestuft oder wird im Rahmen einer PKI-Migration außer Betrieb genommen.
• Ein Knoten wird umbenannt, erhält eine neue IP-Adresse oder wird hinter einem neuen Load-Balanced-Hostnamen hinzugefügt, wodurch sich der CN oder SAN ändert, den das Zertifikat abdecken muss.
• Die Organisation wechselt vom standardmäßigen selbstsignierten Zertifikat zu einem von einer externen oder internen Zertifizierungsstelle ausgestellten Zertifikat.
• Es besteht der Verdacht, dass Administrator-Anmeldeinformationen mit Zugriff auf Schnittstellen oder die CA-Sektionen kompromittiert wurden, da dieser Zugriff ausreicht, um dieses Zertifikat zu ersetzen.
• Bei einem geplanten Audit oder Penetrationstest wird festgestellt, dass die Schlüssellänge, der Signaturalgorithmus oder die Gültigkeitsdauer des Zertifikats nicht den Richtlinien entsprechen.

Zugriffsrichtlinie: Wer sollte dieses Zertifikat ersetzen können?

Das Hochladen eines neuen Zertifikats in die Weboberfläche, das Hinzufügen eines Eintrags zu den externen vertrauenswürdigen Zertifizierungsstellen und der Neustart des Webdienstes sind administrative Aktionen, die unter den Administratoreinstellungen ausgeführt werden. Das bedeutet, dass jeder, der über diese Zugriffsrechte verfügt, eigenständig ändern kann, welchen Zertifizierungsstellen jeder Browser beim Zugriff auf die Schlüsselverwaltungskonsole vertraut. Diese Berechtigung sollte einer kleinen, benannten Gruppe vorbehalten sein, typischerweise den Systemadministratoren des CipherTrust Managers oder einer dedizierten PKI-Betriebsrolle, und nicht der breiten Benutzergruppe mit allgemeinen Administratorrechten auf dem Gerät. Die Möglichkeit, eine Zertifikatsänderung anzufordern und zu genehmigen, sollte von der Möglichkeit, sie auszuführen, getrennt werden, sofern der Änderungskontrollprozess der Organisation dies zulässt. Vor jeder Änderung an Schnittstellen oder externen vertrauenswürdigen Zertifizierungsstellen, selbst bei routinemäßigen Verlängerungen, sollte ein dokumentiertes Änderungsticket erforderlich sein.

Prüfungsnachweise für Zertifikatsänderungen

Jeder Zertifikatsaustausch über die Weboberfläche sollte eine lückenlose Dokumentation hinterlassen, die ein Prüfer nachvollziehen kann, ohne dass ein Administrator sich an den Vorgang erinnern muss. Mindestens sollten der ursprüngliche Zertifikatsanforderungsschlüssel (CSR), das signierte Zertifikat und seine Zertifizierungsstellenkette, das Änderungsticket oder der Genehmigungsbeleg für die Aktualisierung sowie der Zeitstempel des Neustarts des Dienstes zur Anwendung der Änderung gespeichert werden. Diese Datensätze sollten mit den Protokollen der administrativen Aktivitäten von CipherTrust Manager abgeglichen werden, die Konfigurationsänderungen über die Benutzeroberfläche erfassen. So wird eine unerklärliche Zertifikatsänderung bei einer routinemäßigen Protokollprüfung und nicht erst im Rahmen eines Incident-Response-Anrufs aufgedeckt. Für Organisationen, die Zertifikate in diesem Umfang auf vielen Geräten verwalten, bietet eine zentrale Zertifikatslebenszyklusplattform, die Ausstellung, Verlängerung und Bereitstellung automatisch mit einem Zeitstempel versieht, die ideale Lösung, um diese Nachweise zu generieren, ohne dass eine manuelle Dokumentation erforderlich ist.

Manuelle Zertifikatsersetzung vs. automatisiertes Zertifikatslebenszyklusmanagement

Die obige Vorgehensweise ist ein manueller Prozess, der für einen einzelnen CipherTrust Manager-Knoten praktikabel ist. Sobald ein Unternehmen jedoch einen Cluster mit mehreren Knoten, mehrere Umgebungen oder Dutzende von Appliances in verschiedenen Regionen betreibt, wird die Verwaltung unpraktikabel, da jedes Zertifikat einzeln verfolgt, erneuert und geprüft werden muss – ohne gemeinsame Übersicht über alle Knoten hinweg.

Berücksichtigung	Manueller Austausch	Automatisiertes Zertifikatslebenszyklusmanagement
Ablaufverfolgung	Setzt voraus, dass die 91/7/0-Tage-Protokollwarnungen von CipherTrust Manager pro Knoten erkannt und entsprechend verarbeitet werden.	Kontinuierliche Überwachung und proaktive Erneuerung aller Knoten vor Ablauf der Gültigkeit
Aufwand im großen Maßstab	Linear mit der Anzahl der Knoten; jeder Knoten benötigt seinen eigenen CSR, Upload und Neustart.	Zentralisierte Ausgabe und Bereitstellung für die gesamte Flotte, wobei die Richtlinien konsequent angewendet werden.
Audit-Trail	Manuelle Aufzeichnungen außerhalb des Geräts, bei denen man leicht den Überblick verliert.	Automatische, zeitgestempelte Aufzeichnung von Ausstellung, Verlängerung und Einsatz
Risiko menschlicher Fehler	Höher; ein übersprungener Schritt (z. B. die aktivierte automatische Generierung) kann die Korrektur stillschweigend rückgängig machen.	Niedriger; der Workflow erzwingt jedes Mal die korrekte Reihenfolge
Optimale Bildschirmwahl	Ein einzelner Knoten oder eine kleine, statische Bereitstellung	Cluster-, Multi-Region- oder wachsende CipherTrust Manager-Bereitstellungen

Reaktion auf den Vorfall: Harmloses Ablaufdatum oder echte Kompromittierung?

Die meisten Zertifikatswarnungen auf dieser Schnittstelle sind harmlos: ein abgelaufenes Zertifikat, das niemand beachtet hat, ein Knoten, dem nie ein vertrauenswürdiges Zertifikat zugewiesen wurde, oder eine NTP-Abweichung. Behandeln Sie den Fehler anders und eskalieren Sie ihn, wenn eine der folgenden Bedingungen zutrifft:

• Das Zertifikat hat sich unerwartet geändert, ohne dass ein entsprechendes Änderungsticket oder ein Wartungsfenster verzeichnet ist.
• Das Zertifikat wurde von einer Zertifizierungsstelle unterzeichnet, die in diesem Umfeld von niemandem als zugelassener Aussteller anerkannt wird.
• Im Protokoll der administrativen Aktivitäten ist eine Änderung an Schnittstellen oder externen vertrauenswürdigen Zertifizierungsstellen vermerkt, die von einem Konto vorgenommen wurde, das diese Zugriffsrechte nicht haben sollte, oder zu einem Zeitpunkt, an dem niemand arbeitete.
• Nutzer berichten, dass die Warnung nur sporadisch und nicht regelmäßig auftritt, was darauf hindeuten kann, dass der Datenverkehr von einem nicht autorisierten Zertifikat abgefangen wird und nicht auf ein einfaches Konfigurationsproblem.

Wenn einer dieser Punkte zutrifft, ignorieren Sie die Warnung nicht einfach und stellen Sie kein Ersatzzertifikat aus. Rufen Sie das administrative Aktivitätsprotokoll des betroffenen Knotens ab, ermitteln Sie, wer die Änderung vorgenommen hat und von wo aus, ändern Sie die Anmeldeinformationen aller Konten mit Schnittstellen- oder CA-Zugriff und betrachten Sie die CipherTrust Manager-Konsole selbst als potenziell betroffenes System, da sie sich vor den Verschlüsselungsschlüsseln der Organisation befindet. Erst nach Abschluss dieser Untersuchung sollte das Zertifikat neu ausgestellt und der Vorfall zusammen mit den oben beschriebenen Prüfnachweisen dokumentiert werden.

Einschränkungen

Dieser Leitfaden beschreibt das TLS-Zertifikat, das den Browserzugriff auf die Weboberfläche des CipherTrust Managers sichert. Er behandelt nicht die zertifikatbasierte Benutzerauthentifizierung an dieser Oberfläche, Zertifikate, die der CipherTrust Manager im Auftrag anderer Systeme über seine eigenen CA-Dienste ausstellt oder verwaltet, oder die separaten Schnittstellen KMIP und NAE-XML, die unabhängig voneinander im selben Abschnitt „Schnittstellen“ konfiguriert werden. Menübezeichnungen und Klickpfade können je nach CipherTrust Manager-Version leicht variieren. Überprüfen Sie die genauen Schritte anhand der offiziellen Dokumentation von Thales für Ihre spezifische Version, bevor Sie Änderungen in einer Produktionsumgebung vornehmen.

Was würde Encryption Consulting empfehlen?

Wir würden die Verwaltung des Webinterface-Zertifikats nicht manuell durchführen, insbesondere wenn ein Unternehmen mehrere CipherTrust Manager-Knoten betreibt. Unsere CertSecure Manager- Plattform bietet Teams für das Zertifikatslebenszyklusmanagement eine zentrale Ermittlung, Erneuerung und Überwachung genau dieser Art von administrativen Interface-Zertifikaten. So wird der Ablauf zu einem geplanten Ereignis und nicht zu einer zufälligen Browserwarnung. Für Unternehmen, die noch keine interne Zertifizierungsstelle (CA) zur Ausstellung vertrauenswürdiger Zertifikate für Appliances wie CipherTrust Manager besitzen, stellt unser PKI-as-a-Service- Angebot diese Ausstellungsfunktion ohne den Aufwand für den Betrieb einer eigenen CA bereit. Und falls Ihr Team über diesen spezifischen Fehler hinausgehende Probleme bei der CipherTrust Manager-Bereitstellung behebt, bieten unsere CipherTrust Manager-Support-Services die praktische Expertise von Thales für Konfigurations-, Migrations- und Clustering-Fragen.

Fazit

Der Zertifikatsfehler in der Weboberfläche von CipherTrust Manager lässt sich fast immer auf eine von vier Ursachen zurückführen: eine nicht vertrauenswürdige Zertifizierungsstelle, ein abgelaufenes oder noch nicht gültiges Zertifikat, eine Hostnamen-Diskrepanz oder ein veralteter Browser-Cache nach einer legitimen Änderung. Die Behebung ist unkompliziert, sobald die Ursache bekannt ist. Eine robuste Bereitstellung unterscheidet sich von einer, die im nächsten Jahr erneut auf diesen Fehler stoßen wird, dadurch, dass das Zertifikat selbst als verwaltetes Gut behandelt wird – mit einem benannten Eigentümer, einem Rotationsplan, der an die Ablaufwarnungen von CipherTrust Manager gekoppelt ist, eingeschränktem Zugriff zum Ändern des Zertifikats und einem Audit-Trail, der jede Änderung nachträglich dokumentiert.

FAQ

Was bedeutet NET::ERR_CERT_AUTHORITY_INVALID auf der Weboberfläche des CipherTrust Managers?
Das bedeutet, dass der Browser die Zertifizierungsstelle (CA), die das vom Interface präsentierte Zertifikat signiert hat, nicht verifizieren konnte. Dies ist beim ersten Zugriff auf einen neuen CipherTrust Manager-Knoten zu erwarten, da dieser mit einem selbstsignierten Zertifikat seiner lokalen CA ausgeliefert wird. Diese Meldung erscheint auch nach der Installation eines extern signierten Zertifikats, falls die Stamm- und Zwischenzertifikate dieser CA nicht zu den externen vertrauenswürdigen CAs hinzugefügt wurden.

Warum verwendet CipherTrust Manager standardmäßig ein selbstsigniertes Zertifikat?
Das Gerät benötigt ein gültiges HTTPS-Zertifikat, bevor ein Administrator die Benutzeroberfläche erreichen und weitere Einstellungen vornehmen kann. Daher generiert es bei der Initialisierung automatisch ein solches Zertifikat von seiner lokalen Zertifizierungsstelle. Dieses Zertifikat ist zwar funktionsfähig, wird aber von externen Browsern und Betriebssystemen erst dann als vertrauenswürdig eingestuft, wenn es durch ein Zertifikat ersetzt wird, das von einer Zertifizierungsstelle signiert ist, der Ihre Umgebung bereits vertraut.

Wie oft sollte das Zertifikat der CipherTrust Manager-Weboberfläche ausgetauscht werden?
Rotieren Sie es, bevor es die von CipherTrust Manager intern protokollierten Ablaufschwellen von 91, 7 und 0 Tagen erreicht, und behandeln Sie jeden organisatorischen Auslöser, wie z. B. einen vermuteten Verstoß gegen die Anmeldeinformationen, eine Änderung des Hostnamens oder die Außerdienststellung einer Zertifizierungsstelle, als sofortiges Rotationsereignis, unabhängig davon, wo sich das Zertifikat in seinem Gültigkeitszeitraum befindet.

Kann ich ein öffentlich vertrauenswürdiges CA-Zertifikat für die Administratoroberfläche des CipherTrust Managers verwenden?
Ja, sofern der Hostname des CipherTrust Managers auflösbar ist und von der Zertifizierungsstelle validiert werden kann. Die meisten Organisationen stellen dieses Zertifikat jedoch von einer internen Unternehmens- oder privaten Zertifizierungsstelle aus, da die Verwaltungsschnittstelle in der Regel auf interne Netzwerke beschränkt ist und keine Validierung durch eine öffentliche Zertifizierungsstelle benötigt.

Wird ein Zertifikat, das auf einen Knoten hochgeladen wird, automatisch auf den gesamten CipherTrust Manager-Cluster angewendet?
Nein. Webinterface-Zertifikate werden pro Knoten konfiguriert und nicht automatisch clusterweit repliziert, genauso wie Backup-Schlüssel auf jedem Knoten separat verwaltet werden müssen. Jeder Knoten benötigt einen eigenen CSR, ein signiertes Zertifikat und muss dieses über die Administratoreinstellungen hochladen.

Referenzen

• Thales-Dokumentation: CipherTrust Manager-Zertifizierungsstelle
• Thales-Dokumentation: Schnittstellen des CipherTrust Managers
• Thales-Dokumentation: Zertifikatsbasierte Authentifizierung
• Thales: CipherTrust Manager – Übersicht