Securing access to the web interface of managed switches is one of those tasks that seems trivial on paper. On recent hardware, it is indeed trivial. On HP ProCurve V1910 switches—Comware v5 switches that are still used in many home labs and small infrastructures—it's a different story. This article documents the entire project, the pitfalls, the discoveries, and an honest conclusion about what it's really worth.
The test infrastructure: three HP V1910 switches (firmware 5.20 Release 1519P06) on a dedicated, isolated management VLAN with no Internet access. An internal CA based on OpenSSL runs on a Linux server in the infrastructure.
What we thought we would do
The theoretical procedure seemed simple:
- Generate a certificate signed by the internal CA
- Import it onto the switch
- Enable HTTPS with this certificate
Spoiler: none of these three steps went as planned.
Problem #1 — The ECDSA CA
The first obstacle is fundamental. The internal CA was created with the ECDSA (prime256v1) algorithm — a modern choice that is perfectly valid for most uses. It is fully operational and already signs certificates for many pieces of infrastructure equipment: Synology NAS, firewall interface, TrueNAS, Proxmox, and others. There is no doubt about how it works.
The problem lies elsewhere: Comware v5 only supports RSA. And it's not just the final certificate that must be in RSA — it's the entire chain, including the root CA certificate.
As a result, the switch categorically refuses to import an ECDSA CA certificate, even when provided with its SHA1 fingerprint. All other infrastructure equipment accepts certificates from this CA without issue—this is a limitation specific to Comware v5, not a CA problem.
Solution: Create an RSA CA dedicated to legacy equipment, independent of the existing ECDSA CA.
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=US/ST=United States/L=Washington/O=MyOrg/OU=MyCA/CN=MyInternalCA-RSA" \
-out /etc/cert/myCA-rsa/ca.cert.pem
Verification:
openssl x509 -in /etc/cert/myCA-rsa/ca.cert.pem -noout -text | grep "Public Key Algorithm"
# Public Key Algorithm: rsaEncryption ✅
Problem #2 — Extended command mode
By default, the V1910 CLI in SSH access is extremely limited. The system-view, pki, and ssl commands — nothing works. The switch runs in restricted user mode.
The solution comes from some excellent French documentation found on smnet.fr (Eddy and Stéphane Maas): the V1910 has a hidden extended command mode, which can be activated with a command that is not documented in the official HP manuals.
_cmdline-mode on
The switch asks for confirmation [Y/N] and then a password: 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.
⚠️ This mode is disabled each time the device is restarted. It must be reactivated for each configuration session.
After activation, system-view becomes available and you can access the entire Comware v5 CLI.
Problem #3 — The switch cannot import an external private key
Logical attempt: generate key + CSR + certificate on the Linux server, import everything to the switch via a PEM or PKCS#12 file. All attempts failed:
- Import PEM bundle (cert + key):
No certificate or No certificate matched with hostkey - Import P12 with modern OpenSSL:
Fail to parse pkcs#12 file - Import P12 with
-legacy(RC2-40-CBC):Fail to parse pkcs#12 file - Import P12 with
-certpbe PBE-SHA1-3DES: silently ignored
The reason: the Comware v5 switch does not support importing external private keys. The public-key local command only offers create, destroy, and export — no import.
The correct procedure: let the switch generate its own RSA key, retrieve the CSR it generates, sign it on the Linux server, and re-import only the signed certificate.
The procedure that works
On the Linux server — Prepare the extension file
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="" csr="" _cmdline-mode="" on="" #="" y="" +="" 512900="" system-view="" rsa="" 2048="" public-key="" local="" create="" taille="" :="" créer="" l'entité="" pki="" entity="" nom-switch="" common-name="" nom-switch.domaine.local="" country="" fr="" state="" france="" locality="" paris="" organization="" monorg="" organization-unit="" network="" quit="" domaine="" domain="" ma-ca="" ca="" identifier="" 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="" mode="" manual="" importer="" certificat="" import-certificate="" pem="" filename="" flash:="" myca-rsa.cer="" request-certificate="" pkcs10="" affiche="" au="" format="" pem.="" copier="" tout="" bloc="" `-----begin="" request-----`="" ...="" `-----end="" request-----`.="" serveur="" linux="" signer="" ```bash="" coller="" dans="" un="" fichier="" cat=""> /tmp/switch.csr <<eof -----begin="" certificate="" request-----="" [contenu="" du="" csr="" copié="" depuis="" le="" switch]="" -----end="" eof="" #="" signer="" avec="" la="" ca="" rsa="" openssl="" x509="" -req="" \="" -in="" tmp="" switch.csr="" -ca="" etc="" cert="" myca-rsa="" ca.cert.pem="" -cakey="" private="" ca.key.pem="" -cacreateserial="" -out="" switch.cert.pem="" -days="" 825="" -sha256="" -extfile="" ext-switch.cnf="" vérification="" verify="" -cafile="" ```="" ###="" sur="" switch="" —="" importer="" certificat="" et="" activer="" https="" uploader="" `switch.cert.pem`="" `myca-rsa.cer`="" via="" l'interface="" web="" (`device="" →="" file="" management`),="" puis="" dans="" cli="" :="" pki="" import-certificate="" local="" domain="" ma-ca="" pem="" filename="" flash:="" import="" successfully.="" ssl="" server-policy="" https-policy="" pki-domain="" quit="" undo="" ip="" enable="" ssl-server-policy="" save="" ---="" ##="" problème="" n°4="" crl="" check="" si="" l'import="" retourne="" `fail="" to="" certificate`="" malgré="" une="" chaîne="" valide,="" c'est="" **crl="" check**="" qui="" bloque.="" activé="" par="" défaut,="" tente="" de="" contacter="" liste="" révocation="" n'existe="" pas="" notre="" infrastructure="" interne.="" solution="" configuration="" domaine="" disable="" ce="" paramètre="" est="" à="" ajouter="" **avant**="" tentative="" d'import="" local.="" point="" blocage="" plus="" difficile="" diagnostiquer="" car="" message="" d'erreur="" ne="" mentionne="" les="" crl.="" n°5="" tftp="" fonctionne="" pour="" transférer="" fichiers="" transfert="" des="" certificats="" serveur="" linux="" échec.="" commande="" (syntaxe="" `tftp="" [ip]="" get="" [fichier]`)="" initie="" bien="" connexion="" mais="" échoue="" silencieusement,="" probablement="" cause="" ports="" udp="" éphémères="" utilisés="" protocole="" règles="" firewall="" inter-vlan.="" **solution="" contournement="" :**="" utiliser="" management`)="" directement="" poste="" travail.="" simple,="" fiable,="" sans="" dépendance="" réseau="" complexe.="" n°6="" ssh="" se="" déconnecte="" immédiatement="" mobaxterm,="" s'établit="" coupe="" received="" ssh2_msg_channel_open_failure="" for="" nonexistent="" channel="" 1="" mobaxterm="" d'ouvrir="" un="" canal="" sftp="" en="" parallèle="" session="" alimenter="" son="" explorateur="" intégré.="" switches="" hp="" v1910="" supportent="" ferment="" connexion.="" désactiver="" navigateur="" 1.="" ouvrir="" clic="" droit="" **edit="" session**="" 2.="" onglet="" **ssh**="" 3.="" décocher="" **"sftp="" browser"**="" 4.="" sauvegarder="" reconnecter="" après="" cette="" modification.="" manipulation="" règle="" grande="" majorité="" problèmes="" matériel="" comware="" legacy="" sous="" mobaxterm.=""> 💡 If the connection still fails from a command line OpenSSH client (not MobaXterm), you must also force the legacy algorithms:
> bash
> ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 \
> -oHostKeyAlgorithms=+ssh-rsa \
> -oCiphers=+aes128-cbc,3des-cbc \
> admin@192.168.X.X
>
---
## The honest conclusion — is HTTPS worth it on this hardware?
The end result works. The switch does indeed have a certificate signed by the internal CA, and the connection is encrypted. But there are some important nuances.
**What HTTPS really brings here:**
- Switch authentication — we can be sure we are connecting to the right equipment.
- Encryption of management traffic — credentials are not transmitted in clear text.
- A security posture consistent with the rest of the infrastructure.
**The inevitable compromises:**
Comware v5 only supports **TLS 1.0**. Modern browsers (Chrome, Firefox, Edge, Waterfox in default configuration) have been rejecting TLS 1.0 for several years. This leaves us with an uncomfortable choice:
- **Option A — Legacy browser (Basilisk)**: natively supports TLS 1.0, but does not support modern WebExtensions. Result: KeePassXC-Browser cannot be used for password autofill. The password manager must be used manually by copying and pasting.
- **Option B — Modern browser (Waterfox) with TLS 1.0 reactivated**: `about:config` → `security.tls.version.min` = `1`. KeePassXC-Browser can be used again, but a vulnerable protocol (POODLE, BEAST) is deliberately reactivated.
- **Option C — Stay with HTTP**: no encryption, but a modern browser and functional password manager.
**The verdict:**
On an isolated management VLAN, with no default gateway in the switch configuration and inter-VLAN access strictly controlled by the firewall, TLS 1.0 attacks require physical or logical access to the network segment. The actual risk is low.
Option B (Waterfox + TLS 1.0 reactivated) is the most pragmatic compromise: we retain the security of certificate authentication, traffic encryption (even if imperfect), and the ergonomics of a password manager.
But let's be honest: setting up an internal PKI, a dedicated RSA CA, correctly signed certificates, and ending up with TLS 1.0 with `security.tls.version.min=1` in the browser—this is the kind of project that produces a technically correct result but offers modest real security benefits on this type of legacy hardware.
That's also what infrastructure administration is all about: knowing how far to push the envelope and honestly documenting why you stopped there.
---
## Summary of key points
| Problem | Solution |
|---|---|
| ECDSA CA rejected | Create a dedicated RSA CA for legacy equipment |
| Restricted CLI | `_cmdline-mode on` + password `512900` |
| Private key import impossible | The switch generates its own CSR |
| `Fail to verify certificate` | `crl check disable` in the PKI domain |
| TFTP not working | Upload via web interface (File Management) |
| SSH fails | Force legacy algorithms with `-oKexAlgorithms` |
| Browser rejects TLS 1.0 | `security.tls.version.min=1` in `about:config` |
---
## Resources
The reference documentation that enabled extended command mode and CLI syntax for V1910:
**smnet.fr — HP v1910 Switch** by Eddy and Stéphane Maas
`https://www.smnet.fr/hp/v1910/hp-v1910.html`
A rare, accurate, and well-illustrated French resource on this hardware. The section on terminal mode and extended commands is particularly valuable.
The H3C (original manufacturer of Comware v5) knowledge base for PKI errors:
`https://knowledge.h3c.com`
---
*Aperture Zone — "It works, but sometimes it only works halfway. (At least we know why.)"*</eof></eof>