Punkt 1 oben ist selbsterklärend. Um festzustellen, ob 2 oben zutrifft, rufen Sie zunächst die Liste der vertrauenswürdigen Hosts in der DD ab:
# adminaccess trust show
Überprüfen Sie für jeden der Hosts, mit denen dieser Host eine Vertrauensstellung hat, den Upgradeverlauf, um festzustellen, ob einer mit DDOS 5.4 (oder früher) oder DDMC 1.1 (oder früher) installiert wurde:
# system upgrade history
Bei Systemen, die mit einer der oben genannten Versionen installiert wurden, wurde wahrscheinlich ein selbstsigniertes CA-Zertifikat mit öffentlichen Schlüsseln von nur 1024 Bit erzeugt, die vom JDK nach dem Upgrade auf DDOS/DDMC 7.1 nicht mehr akzeptiert werden. Eine Möglichkeit, herauszufinden, ob diese Hosts Zertifikate mit kleinen öffentlichen Schlüsseln haben, besteht darin, ihnen die GUI anzuzeigen und die Zertifikatdetails in einem Browser zu überprüfen (die Art und Weise, dies zu tun, variiert leicht je nach Browser).
Um Element 3 zu bestätigen (wenn die DD-GUI-Fehlerprotokolle für dieses spezifische Problem gelten), führen Sie den folgenden Befehl aus, um die Protokolldatei "em.info" zu öffnen:
# log view debug/sm/em.info
Und suchen Sie (verwenden Sie einen Schrägstrich), um nach diesen Protokollen zu suchen ("..." gibt an, dass einige Protokolle unten der Kürze halber nicht aufgeführt sind) :
+-----+-----+-----+ SYSTEM(NEU)START +-----+-----+-----+
...
26 Feb 2021 10:33:04,172 INFO [main] Setzen des Session-Cookie-Namens auf 'JSESSIONID-ddem___HTTPS'26
Feb 2021 10:33:04,172 INFO [main] Festlegen des XSRF-Cookie-Namens auf 'DD_SSO_TOKEN___HTTPS'26
Feb 2021 10:33:04,382 INFO [main] Injizieren der X.509-Factory des SUN-Anbieters, um Validierungsprobleme
zu beheben ...
26 Feb 2021 10:33:05,093 INFO [main] Erneute Initialisierung der Zertifikate zwischen dem Client und dem Server
26 Feb 2021 10:33:05,093 INFO [main] Erneutes Laden der Zertifikatsspeicher für das System
26 Feb 2021 10:33:05,097 INFO [main] Neuladen der Zertifikatsspeicher
abgeschlossen26 Feb 2021 10:33:05,097 FEHLER [main] Ausnahme während der Befehlsausführung: javax.net.ssl.SSLException - Fehler beim Erstellen des Premaster-Schlüssels. , wird es erneut versuchen, Versuch # 1
26 Feb 2021 10:33:05,243 INFO [main] Neuinitialisieren der Zertifikate zwischen Client und Server
26 Feb 2021 10:33:05,243 INFO [main] Neuladen der Zertifikatsspeicher für das System
26 Feb 2021 10:33:05,246 INFO [main] Neuladen der Zertifikatsspeicher abgeschlossen
Dies würde darauf hindeuten, dass einige der Zertifikate, die diese DD als vertrauenswürdig importiert hat, einen kurzen Schlüssel haben und daher die GUI nicht gestartet werden kann.
Obwohl DDOS 7.1 oder höher weiterhin nicht beim Laden der GUI fehlschlägt, wenn Zertifikate mit kleinen öffentlichen Schlüsseln vorgelegt werden, wurde das Problem im Code für die Versionen DDOS 6.2.1.40 und höher und DDOS 7.2.0.50 und höher behoben, so dass, wenn beim Upgrade auf eine solche Version das lokale CA-Zertifikat einen kleinen öffentlichen Schlüssel hat, Das Zertifikat wird mit einem längeren Schlüssel erneut erzeugt.
Wenn man bedenkt, dass zum Zeitpunkt der Erstellung dieses Artikels (August 2022) keine anderen Versionen als DDOS 6.2.1.x (nur für DD2200- und DD250-Hardware) und DDOS 7.x mehr unterstützt werden, wird kein Workaround bereitgestellt, obwohl Sie für die fehlerhaften DDs versuchen können, das Host- und CA-Zertifikat mit längeren Schlüsseln neu zu generieren und dann die Vertrauensstellung zwischen den betroffenen Geräten zu entfernen und erneut hinzuzufügen:
# adminaccess trust del host dd-trusted-1 type mutual
# adminaccess certificate generate self-signed-cert regenerate-ca
# adminaccess trust add host dd-trusted-1 type mutual