Punkt 1 ovan är självförklarande. För att avgöra om 2 ovan gäller, hämta först listan över betrodda värdar i DD:
# adminaccess förtroende visa
För var och en av de värdar som den här har förtroende för, kontrollera deras uppgraderingshistorik, för att se om någon installerades med DDOS 5.4 (eller tidigare) eller DDMC 1.1 (eller tidigare):
# Systemuppgraderingshistorik
System som installeras med någon av versionerna ovan har sannolikt haft ett självsignerat CA-certifikat genererat vid installationen med offentliga nycklar som endast är 1024 bitar långa, som inte längre accepteras av JDK efter uppgradering till DDOS/DDMC 7.1. Ett möjligt sätt att ta reda på om dessa värdar har certifikat med små offentliga nycklar är genom att öppna upp det grafiska användargränssnittet för dem och kontrollera certifikatinformationen från en webbläsare (sättet att göra det varierar något mellan olika webbläsare).
Bekräfta objekt 3 (om DD GUI-felloggarna gäller det här specifika problemet) genom att köra följande kommando för att öppna em.info-loggfilen:
# loggvy debug/sm/em.info
Och sök (använd ett snedstreck) för att söka efter dessa loggar ("..." indikerar att vissa loggar inte visas nedan för korthets skull):
+-----+-----+-----+ SYSTEM(RE)START +-----+-----+-----+
...
26 Feb 2021 10:33:04,172 INFO [main] Ställa in sessionscookiens namn till 'JSESSIONID-ddem___HTTPS'26
Feb 2021 10:33:04,172 INFO [main] Ställa in namnet på xsrf-cookien till 'DD_SSO_TOKEN___HTTPS'26
Feb 2021 10:33:04,382 INFO [main] Injicerar SUN-leverantörens X.509-fabrik för att åtgärda valideringsproblem
...
26 feb 2021 10:33:05,093 INFO [main] Initiera om certifikaten mellan klienten och servern
26 feb 2021 10:33:05,093 INFO [main] Läsa in certifikatarkiven för systemet igen
26 feb 2021 10:33:05,097 INFO [main] Har läst in certifikatarkiven
igen 26 feb 2021 10:33:05,097 FEL [main] Undantag under kommandokörning: javax.net.ssl.SSLException – Fel vid skapande av premaster secret. , kommer att försöka igen, försök # 1
26 feb 2021 10:33:05,243 INFO [main] Initiera om certifikaten mellan klienten och servern
26 feb 2021 10:33:05,243 INFO [main] Läsa in certifikatarkiven för systemet
igen 26 feb 2021 10:33:05,246 INFO [main] Har läst in certifikatarkiven igen
Det skulle tyda på att en del av certifikatet som denna DD har importerat som betrott har en kort nyckel och att det grafiska användargränssnittet därför inte kan starta.
Även om DDOS 7.1 eller senare fortsätter att misslyckas med att läsa in det grafiska användargränssnittet när det presenteras med certifikat med små publika nycklar, har problemet lösts i koden för version DDOS 6.2.1.40 och senare, och DDOS 7.2.0.50 och senare, så att om det lokala CA-certifikatet har en liten offentlig nyckel när du uppgraderar till en sådan utgåva, Certifikatet återskapas med en längre nyckel.
Med tanke på att det i skrivande stund (augusti 2022) inte längre finns stöd för några andra versioner än DDOS 6.2.1.x (endast för DD2200- och DD250-hårdvara) och DDOS 7.x, finns det ingen lösning, men för de DD:er som bryter mot reglerna kan du försöka återskapa värden och CA-certifikatet med längre nycklar och sedan ta bort och lägga till förtroende igen mellan de berörda enheterna:
# 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