Data Domain : Après la mise à niveau vers DDOS/DDMC 7.1.x ou une version ultérieure, l’interface utilisateur n’est plus accessible

Un client met à niveau DDOS ou DDMC vers la version 7.1.x ou une version ultérieure (à partir de maintenant, nous utiliserons DDOS pour faire référence à DDOS et DDMC). Pour plus de brièveté, il découvre, une fois la mise à niveau terminée, qu’il n’est plus possible d’accéder à l’interface graphique. Le redémarrage des services HTTP/HTTPS à partir de la ligne de commande ne permet pas non plus de le faire fonctionner. Lorsque vous utilisez un navigateur pour accéder à l’interface utilisateur, la page d’erreur suivante affiche: 
 

Service non disponible

Le service gui est temporairement indisponible. Actualisez le navigateur pour réessayer. Si le problème persiste, contactez le support Dell EMC pour obtenir de l’aide.

Le back-end de l’interface utilisateur est en cours d’exécution à partir d’une application Java. Le back-end de l’interface utilisateur n’est pas en cours d’exécution. Si ce DD a été mis à niveau vers DDOS 7.1.x ou une version ultérieure et que l’interface graphique a échoué depuis, si le DD a une relation de confiance avec d’autres DD et que l’un d’entre eux dispose d’un cerificate avec une clé publique inférieure à 2 048 bits, cela peut être la raison pour laquelle l’interface graphique DD ne démarre pas, car les vérifications plus strictes dans le JDK fourni le plus récent ne parviennent pas à passer pour certains des hôtes DD de confiance.

Tout d’abord, il est nécessaire de déterminer qu’il s’agit exactement du problème rencontré. Pour que cela soit le cas, toutes les conditions ci-dessous doivent tenir:

1. DD où l’interface graphique ne démarre pas rencontre des problèmes d’interface graphique uniquement depuis la mise à niveau vers DDOS 7.1.x ou une version ultérieure
2. Ce DD a une relation de confiance avec d’autres DD, dont un ou plusieurs avaient exécuté une version de DDOS 5.4.x (ou une version antérieure) ou DDMC 1.1 (ou version antérieure) par le passé.
3. Ce DD dispose d’un ensemble particulier de logs pour l’échec du démarrage du back-end de l’interface utilisateur

L’élément 1 ci-dessus est explicite. Pour déterminer si 2 options ci-dessus s’appliquent, commencez par obtenir la liste des hôtes de confiance dans DD:

# adminaccess trust show

Pour chacun des hôtes avec lesquels celui-ci a une relation de confiance, vérifiez son historique de mise à niveau pour voir s’il a été installé avec DDOS 5.4 (ou version antérieure) ou DDMC 1.1 (ou version antérieure): 

# Historique de mise à niveau du système

Les systèmes installés avec l’une des versions ci-dessus sont susceptibles de disposer d’un certificat auto-signé de l’autorité de certification généré sur l’installation avec des clés publiques de seulement 1 024 bits, qui ne sont plus acceptées par JDK après la mise à niveau vers DDOS/DDMC 7.1. Pour savoir si ces hôtes disposent de certificats dotés de petites clés publiques, il est possible d’ouvrir l’interface utilisateur et de vérifier les détails du certificat à partir d’un navigateur (la façon de le faire varie légèrement d’un navigateur à l’autre).

Pour confirmer l’élément 3 (si les journaux d’échec de l’interface utilisateur DD concernent ce problème spécifique), exécutez la commande suivante pour ouvrir le fichier journal « em.info »:

# log view debug/sm/em.info

Et recherchez (utilisez une barre oblique) pour rechercher ces logs (« ... » indique que certains logs ne sont pas affichés ci-dessous pour des raisons de brièveté):

 

+-----+-----+-----+ SYSTÈME (RE)START +-----+-----+-----+
...
26 février 2021 10:33:04,172 INFO [main] Setting the session cookie name to 'JSESSIONID-ddem___HTTPS'26
feb 2021 10:33:04,17 2 INFO [main] Définition du nom du cookie xsrf sur « DD_SSO_TOKEN___HTTPS
26 février 2021 10:33:04,382 INFO [main] Injecting the SUN Provider’s X.509 factory to fix validation issues
...
26 février 2021 10:33:05,093 INFO [main] Réin initialisation des certificats entre le client et le serveur

26 février 2021 10:33:05,093 INFO [main] Rechargement des magasins de certificats pour le système

26 février 2021 10:33:05,097 INFO [main] Finished reloading the certificate stores
26 Feb 2021 10:33:05,097 ERROR [main] Exception during command execution: javax.net.ssl.SSLException - Error creating premaster secret. , réessayez, tentative n° 1
26 février 2021 10:33:05,243 INFO [main] Réin initialisation des certificats entre le client et le serveur
26 février 2021 10:33:05 243 INFO [main] Rechargement des magasins de certificats pour le système
26 février 2021 10:33:05,246 INFO [main] Terminé le rechargement des magasins de certificats

 Cela indique que certains des certificats que ce DD a importés en tant que fiables ont une clé courte et que l’interface utilisateur ne peut donc pas démarrer.

Bien que DDOS 7.1 ou version ultérieure continue de ne pas charger l’interface graphique lorsqu’elle est présentée avec des certificats avec de petites clés publiques, le problème a été résolu dans le code pour les versions DDOS 6.2.1.40 et ultérieures, et DDOS 7.2.0.50 et versions ultérieures, de sorte que si lors de la mise à niveau vers une telle version, le certificat d’autorité de certification local dispose d’une petite clé publique, le certificat sera recréé avec une clé plus longue.
 

Compte tenu de cette écriture (août 2022), aucune version autre que DDOS 6.2.1.x (pour le matériel DD2200 et DD250 uniquement) et DDOS 7.x n’est plus prise en charge. Aucune solution de contournement n’est fournie. Bien que pour les DD concernés, vous puissiez essayer de recréer le certificat de l’hôte et de l’autorité de certification avec des clés plus longues, puis supprimer et rajouter la confiance entre les périphériques concernés: 

# 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