HTTPS sur HP ProCurve V1910

Sécuriser l’accès à l’interface web de ses switches managés, c’est une de ces tâches qui semble anodine sur le papier. Sur du matériel récent, c’est effectivement trivial. Sur des HP ProCurve V1910 — des switches Comware v5 qui équipent encore beaucoup de homelabs et de petites infrastructures — c’est une autre histoire. Cet article documente le chantier complet, les embûches, les découvertes, et la conclusion honnête sur ce que ça vaut vraiment.

L’infrastructure de test : trois switches HP V1910 (firmware 5.20 Release 1519P06) sur un VLAN de management dédié, isolé, sans accès Internet. Une CA interne basée sur OpenSSL tourne sur un serveur Linux de l’infra.

Ce qu’on pensait faire

La procédure théorique semblait simple :

Générer un certificat signé par la CA interne
L’importer sur le switch
Activer HTTPS avec ce certificat

Spoiler : aucune de ces trois étapes ne s’est passée comme prévu.

Problème n°1 — La CA ECDSA

Le premier obstacle est fondamental. La CA interne avait été créée avec l’algorithme ECDSA (prime256v1) — un choix moderne et parfaitement valide pour la plupart des usages. Elle est d’ailleurs pleinement opérationnelle et signe déjà les certificats de nombreux équipements de l’infra : NAS Synology, interface du firewall, TrueNAS, Proxmox, et d’autres. Pas de doute sur son fonctionnement.

Le problème est ailleurs : le Comware v5 ne supporte que RSA. Et ce n’est pas uniquement le certificat final qui doit être en RSA — c’est toute la chaîne, y compris le certificat de la CA racine.

Résultat : le switch refuse catégoriquement d’importer un certificat CA ECDSA, même en fournissant son fingerprint SHA1. Tous les autres équipements de l’infra acceptent parfaitement les certificats de cette CA — c’est bien une limitation spécifique au Comware v5, pas un problème de CA.

Solution : Créer une CA RSA dédiée aux équipements legacy, indépendante de la CA ECDSA existante.

mkdir -p /etc/cert/myCA-rsa/private /etc/cert/myCA-rsa/newcerts
touch /etc/cert/myCA-rsa/index.txt
echo 1000 > /etc/cert/myCA-rsa/serial

openssl genrsa -out /etc/cert/myCA-rsa/private/ca.key.pem 2048

openssl req -x509 -new \
  -key /etc/cert/myCA-rsa/private/ca.key.pem \
  -sha256 -days 3650 \
  -subj "/C=FR/ST=France/L=Paris/O=MonOrg/OU=MyCA/CN=MyInternalCA-RSA" \
  -out /etc/cert/myCA-rsa/ca.cert.pem

Vérification :

openssl x509 -in /etc/cert/myCA-rsa/ca.cert.pem -noout -text | grep "Public Key Algorithm"
# Public Key Algorithm: rsaEncryption ✅

Problème n°2 — Le mode commandes étendues

Par défaut, la CLI du V1910 en accès SSH est extrêmement limitée. Les commandes system-view, pki, ssl — rien ne fonctionne. Le switch tourne en mode utilisateur restreint.

La solution vient d’une excellente documentation française trouvée sur smnet.fr (Eddy et Stéphane Maas) : le V1910 dispose d’un mode commandes étendues caché, activable avec une commande non documentée dans les manuels officiels HP.

_cmdline-mode on

Le switch demande une confirmation [Y/N] puis un mot de passe : 512900

Warning: Now you enter an all-command mode for developer's testing,
some commands may affect operation by wrong use,
please carefully use it with our engineer's direction.

⚠️ Ce mode se désactive à chaque redémarrage. Il faudra le réactiver à chaque session de configuration.

Après activation, system-view devient disponible et on accède à toute la CLI Comware v5.

Problème n°3 — Le switch ne peut pas importer une clé privée externe

Tentative logique : générer clé + CSR + certificat sur le serveur Linux, importer le tout sur le switch via un fichier PEM ou PKCS#12. Toutes les tentatives ont échoué :

Import PEM bundle (cert + key) : No certificate or No certificate matched with hostkey
Import P12 avec OpenSSL moderne : Fail to parse pkcs#12 file
Import P12 avec -legacy (RC2-40-CBC) : Fail to parse pkcs#12 file
Import P12 avec -certpbe PBE-SHA1-3DES : silencieusement ignoré

La raison : le switch Comware v5 ne supporte pas l’import de clé privée externe. La commande public-key local ne propose que create, destroy et export — pas d’import.

La bonne procédure : laisser le switch générer sa propre clé RSA, récupérer le CSR qu’il génère, le signer sur le serveur Linux, et réimporter uniquement le certificat signé.

La procédure qui fonctionne

Sur le serveur Linux — Préparer le fichier d’extensions

cat > /tmp/ext-switch.cnf <<EOF
subjectAltName = IP:192.168.X.X, DNS:nom-switch.domaine.local
authorityKeyIdentifier = keyid,issuer
EOF

Sur le switch — Générer la clé et le CSR

_cmdline-mode on
# Y + 512900
system-view

# Générer la clé RSA 2048
public-key local create rsa
# Taille : 2048

# Créer l'entité PKI
pki entity NOM-SWITCH
  common-name nom-switch.domaine.local
  country FR
  state France
  locality Paris
  organization MonOrg
  organization-unit Network
  quit

# Créer le domaine PKI
pki domain MA-CA
  ca identifier MA-CA
  root-certificate fingerprint sha1 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
  crl check disable
  certificate request entity NOM-SWITCH
  certificate request mode manual
  quit

# Importer le certificat CA RSA
pki import-certificate ca domain MA-CA pem filename flash:/myca-rsa.cer

# Générer le CSR
pki request-certificate domain MA-CA pkcs10

Le switch affiche le CSR au format PEM. Copier tout le bloc -----BEGIN CERTIFICATE REQUEST----- … -----END CERTIFICATE REQUEST-----.

Sur le serveur Linux — Signer le CSR

# Coller le CSR dans un fichier
cat > /tmp/switch.csr <<EOF
-----BEGIN CERTIFICATE REQUEST-----
[contenu du CSR copié depuis le switch]
-----END CERTIFICATE REQUEST-----
EOF

# Signer avec la CA RSA
openssl x509 -req \
  -in /tmp/switch.csr \
  -CA /etc/cert/myCA-rsa/ca.cert.pem \
  -CAkey /etc/cert/myCA-rsa/private/ca.key.pem \
  -CAcreateserial \
  -out /tmp/switch.cert.pem \
  -days 825 -sha256 \
  -extfile /tmp/ext-switch.cnf

# Vérification
openssl verify -CAfile /etc/cert/myCA-rsa/ca.cert.pem /tmp/switch.cert.pem

Sur le switch — Importer le certificat et activer HTTPS

Uploader switch.cert.pem et myca-rsa.cer via l’interface web du switch (Device → File Management), puis dans la CLI :

pki import-certificate local domain MA-CA pem filename flash:/switch.cert.pem
# Import local certificate successfully.

ssl server-policy HTTPS-POLICY
  pki-domain MA-CA
  quit

undo ip https enable
ip https ssl-server-policy HTTPS-POLICY
ip https enable

save

Problème n°4 — Le CRL check

Si l’import du certificat local retourne Fail to verify certificate malgré une chaîne valide, c’est le CRL check qui bloque. Activé par défaut, le switch tente de contacter une liste de révocation qui n’existe pas dans notre infrastructure interne.

Solution dans la configuration du domaine PKI :

pki domain MA-CA
  crl check disable
  quit

Ce paramètre est à ajouter avant la tentative d’import du certificat local. C’est le point de blocage le plus difficile à diagnostiquer car le message d’erreur ne mentionne pas les CRL.

Problème n°5 — Le TFTP ne fonctionne pas pour transférer les fichiers

Tentative de transfert des certificats via TFTP depuis le serveur Linux : échec. La commande TFTP du switch (syntaxe tftp [IP] get [fichier]) initie bien une connexion mais le transfert échoue silencieusement, probablement à cause des ports UDP éphémères utilisés par le protocole et des règles de firewall inter-VLAN.

Solution de contournement : utiliser l’interface web du switch (Device → File Management) pour uploader les fichiers directement depuis le poste de travail. Simple, fiable, sans dépendance réseau complexe.

Problème n°6 — SSH qui se déconnecte immédiatement

Depuis MobaXterm, la connexion SSH s’établit puis se coupe immédiatement avec le message :

Received SSH2_MSG_CHANNEL_OPEN_FAILURE for nonexistent channel 1

La cause : MobaXterm tente d’ouvrir un canal SFTP en parallèle de la session SSH pour alimenter son explorateur de fichiers intégré. Les switches HP V1910 ne supportent pas SFTP et ferment immédiatement la connexion.

Solution — Désactiver le navigateur SFTP dans MobaXterm :

Ouvrir la session SSH → clic droit → Edit session
Onglet SSH
Décocher “SFTP browser”
Sauvegarder et se reconnecter

La connexion SSH fonctionne immédiatement après cette modification. Cette manipulation règle la grande majorité des problèmes de connexion SSH sur du matériel HP/Comware legacy sous MobaXterm.

💡 Si la connexion échoue toujours depuis un client OpenSSH en ligne de commande (pas MobaXterm), il faut en plus forcer les algorithmes legacy :
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 \
    -oHostKeyAlgorithms=+ssh-rsa \
    -oCiphers=+aes128-cbc,3des-cbc \
    admin@192.168.X.X

La conclusion honnête — HTTPS vaut-il le coup sur ce matériel ?

Le résultat final fonctionne. Le switch présente bien un certificat signé par la CA interne, la connexion est chiffrée. Mais avec des nuances importantes.

Ce que HTTPS apporte réellement ici :

Authentification du switch — on est sûr de se connecter au bon équipement
Chiffrement du trafic de management — les credentials ne circulent pas en clair
Une posture de sécurité cohérente avec le reste de l’infra

Les compromis inévitables :

Le Comware v5 ne supporte que TLS 1.0. Les navigateurs modernes (Chrome, Firefox, Edge, Waterfox en configuration par défaut) refusent TLS 1.0 depuis plusieurs années. On se retrouve donc face à un choix inconfortable :

Option A — Navigateur legacy (Basilisk) : accepte TLS 1.0 nativement, mais ne supporte pas les extensions WebExtensions modernes. Résultat : impossible d’utiliser KeePassXC-Browser pour l’auto-remplissage des mots de passe. Le gestionnaire de mots de passe doit être utilisé en copier-coller manuel.
Option B — Navigateur moderne (Waterfox) avec TLS 1.0 réactivé : about:config → security.tls.version.min = 1. On récupère KeePassXC-Browser, mais on réactive délibérément un protocole vulnérable (POODLE, BEAST).
Option C — Rester en HTTP : pas de chiffrement, mais navigateur moderne et gestionnaire de mots de passe fonctionnels.

Le verdict :

Sur un VLAN de management isolé, sans passerelle par défaut dans la configuration des switches, avec des accès inter-VLAN strictement contrôlés par le firewall, les attaques TLS 1.0 nécessitent un accès physique ou logique au segment réseau. Le risque réel est faible.

L’option B (Waterfox + TLS 1.0 réactivé) est le compromis le plus pragmatique : on garde la sécurité de l’authentification par certificat, le chiffrement du trafic même imparfait, et l’ergonomie d’un gestionnaire de mots de passe.

Mais il faut être honnête : mettre en place une PKI interne, une CA RSA dédiée, des certificats signés correctement, pour finir sur TLS 1.0 avec security.tls.version.min=1 dans le navigateur — c’est le genre de chantier qui produit un résultat techniquement correct mais dont le bénéfice sécurité réel est modeste sur ce type de matériel legacy.

C’est aussi ça, l’administration d’infrastructure : savoir jusqu’où pousser le curseur, et documenter honnêtement pourquoi on s’est arrêté là.

Récapitulatif des points clés

Problème	Solution
CA ECDSA refusée	Créer une CA RSA dédiée équipements legacy
CLI restreinte	`_cmdline-mode on` + mot de passe `512900`
Import clé privée impossible	Le switch génère son propre CSR
`Fail to verify certificate`	`crl check disable` dans le domaine PKI
TFTP non fonctionnel	Upload via interface web (File Management)
SSH échoue	Forcer les algorithmes legacy avec `-oKexAlgorithms`
Navigateur rejette TLS 1.0	`security.tls.version.min=1` dans `about:config`

Ressources

La documentation de référence qui a permis de débloquer le mode commandes étendues et la syntaxe CLI du V1910 :

smnet.fr — Commutateur HP v1910 par Eddy et Stéphane Maas https://www.smnet.fr/hp/v1910/hp-v1910.html

Une ressource française rare, précise et bien illustrée sur ce matériel. La section sur le mode terminal et les commandes étendues est particulièrement précieuse.

La base de connaissances H3C (fabricant d’origine du Comware v5) pour les erreurs PKI : https://knowledge.h3c.com

Aperture Zone — “Ça marche, mais des fois ça marche qu’à moitié.(En tout cas on sait pourquoi)”