HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen

HTTPS, vorzugsweise mit gültigen Zertifikaten, sollte heute eigentlich Standard sein – erst recht wenn man mehr oder weniger kritische Infrastrukturen darüber verwalten möchte. Auch wenn ich eher ein Verfechter von SSH bei der Konfiguration von Switchen bin, so wird doch oft auch ein Webinterface gefordert. Bei HP/HPE/Aruba/Procurve ist dies in der Standardkonfiguration unverschlüsselt per HTTP erreichbar. HTTPS lässt sich aktivieren, die Einrichtung von etwas anderem als self-signed ist jedoch leider nicht so intuitiv wie ich das gerne hätte. Also gehen wir die Schritte mal durch. Im CLI natürlich.

Erst muss ein „Trust Anchor“ erstellt werden. Dies ist sozusagen die Zertifikatsdatenbank des Switches. Da mehrere vorhanden sein können wird er mit einem aussagekräftigem Namen (her „MEINNETZ„) versehen.

# crypto pki ta-profile MEINNETZ

Anschließend wird das Zertifikat der Zertifizierungsstelle (CA) importiert. Leider ist dies bei vielen  Geräten nur per TFTP und nicht über USB-Stick, Terminal  o.Ä. möglich. Auch dieses bekommt zur besseren Auffindbarkeit einen Namen (hier „MYCA„). Die angegebene IP entspricht der des TFTP-Servers, unter Windows lässt sich hierzu z.B. TFTPD32 nutzen. Der Switch selbst muss hierfür natürlich bereits eine passende Netzwerkkonfiguration besitzen und den PC erreichen können, ohne passende Konfiguration sucht er sich eine Adresse per DHCP auf dem Standard-VLAN.

# copy tftp ta-certificate MYCA 192.168.0.123 meineca.crt

Im Anschluss kann die Zertifikatsunterschriftanfrage (CSR) generiert werden. Wichtig für ein gültiges Zertifikat ist hierbei im Feld „common-name“ den späteren Hostname oder die IP-Adresse des Switches anzugeben, welche letztendlich für das Management verwendet werden soll..

# crypto pki create-csr certificate-name HTTPS ta-profile MEINNETZ usage web key-type rsa key-size 2048 subject common-name switch123.adlerweb.local org "BitBastelei" org-unit "IT" locality "Koblenz" state RLP country DE

Zu beachten ist, dass je nach Modellgeneration die Verfügbaren Cryptomethoden limitiert sein können. Das hier genutzte Modell unterstützt so leiglich RSA-Schlüssel mit bis zu 2048 Bit. Die verfügbaren Optionen lassen sich wie immer durch „?“ abrufen. Das Erstellen kann je nach verbautem Managementprozessor einige Zeit in Anspruch nehmen, im Anschluss erscheint die Anfrage als Text.

-----BEGIN CERTIFICATE REQUEST-----
MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkVOMQ0wCwYDVQQIDARub25lMQ0wCwYD
VQQHDARub25lMRIwEAYDVQQKDAlXaWtpcGVkaWExDTALBgNVBAsMBG5vbmUxGDAW
BgNVBAMMDyoud2lraXBlZGlhLm9yZzEcMBoGCSqGSIb3DQEJARYNbm9uZUBub25l
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP/U8RlcCD6E8AL
PT8LLUR9ygyygPCaSmIEC8zXGJung3ykElXFRz/Jc/bu0hxCxi2YDz5IjxBBOpB/
kieG83HsSmZZtR+drZIQ6vOsr/ucvpnB9z4XzKuabNGZ5ZiTSQ9L7Mx8FzvUTq5y
/ArIuM+FBeuno/IV8zvwAe/VRa8i0QjFXT9vBBp35aeatdnJ2ds50yKCsHHcjvtr
9/8zPVqqmhl2XFS3Qdqlsprzbgksom67OobJGjaV+fNHNQ0o/rzP//Pl3i7vvaEG
7Ff8tQhEwR9nJUR1T6Z7ln7S6cOr23YozgWVkEJ/dSr6LAopb+cZ88FzW5NszU6i
57HhA7ECAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4IBAQBn8OCVOIx+n0AS6WbEmYDR
SspR9xOCoOwYfamB+2Bpmt82R01zJ/kaqzUtZUjaGvQvAaz5lUwoMdaO0X7I5Xfl
sllMFDaYoGD4Rru4s8gz2qG/QHWA8uPXzJVAj6X0olbIdLTEqTKsnBj4Zr1AJCNy
/YcG4ouLJr140o26MhwBpoCRpPjAgdYMH60BYfnc4/DILxMVqR9xqK1s98d6Ob/+
3wHFK+S7BRWrJQXcM8veAexXuk9lHQ+FgGfD0eSYGz0kyP26Qa2pLTwumjt+nBPl
rfJxaLHwTQ/1988G0H35ED0f9Md5fzoKi5evU1wG5WRxdEUPyt3QUXxdQ69i0C+7
-----END CERTIFICATE REQUEST-----

Diese Anfrage kopiert man aus dem Terminal und reicht sie als .csr-Datei an die gewünschte Zertifizierungsstelle weiter bzw. signiert diesen selbst mit seiner lokalen CA. Als Ergebnis erhält man ein Zertifikat, üblicherweise im PEM-Format (meist .pem oder .crt), welches im Switch importiert werden muss. Erhält man stattdessen eine DER oder P7B-Datei kann diese an einem PC z.B. mit openssl konvertiert werden. Nach Eingabe des Importbefehls erwartet der Switch den Inhalt der PEM-Datei als Texteingabe. Unter Windows mit PuTTy kann mit einem Rechtsklick eingefügt werden.

# crypto pki install-signed-certificate
Paste the certificate here and enter:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Mit Erkennen der „END CERTIFICATE„-Zeile kehrt der Switch automatisch zur Konfigurationsoberfläche zurück.  Das Zertifikat sollte nun in der Liste der installierten Zertifikate zu sehen sein.

# show crypto pki local-certificate
Name Usage Expiration Parent / Profile
-------------------- ------------- -------------- --------------------
HTTPS Web 2345/06/07 MEINNETZ

Zuletzt wird HTTPS ein- und HTTP ausgeschaltet. Das zuvor installierte und somit einzige Zertifikat sollte automatisch verwendet werden.

# web-management ssl
# no web-management plaintext

Somit ist der Switch nicht mehr unverschlüsselt verwaltbar und die zuständigen „Administratoren“ teilen ihr Passwort nicht mehr zwangsläufig allen Lauschern im Netz servierfertig mit. Mit etwas Glück spart das Ganze am Ende mehr Arbeit als das turnusmäßige Auffrischen der Zertifikate verursacht. Wenn nicht schont der nicht mehr vorhandene HTTP-Login  immerhin meine Nerven.

5 Gedanken zu „HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen“

  1. Besten Dank, richtig gute Anleitung!

    Immer wieder spannend wie schwer es einem die Hersteller machen Systeme abzusichern, habe eine Ewigkeit nach einer vernünftigen Anleitung gesucht.

  2. An sich eine schöne Anleitung. Aber: Ich möchte zu Vorsicht dabei raten, HTTPS zu aktivieren, nur weil es geht. Switches sind üblicherweise Infrastruktur, die nicht jeden Tag angefasst wird (entsprechend niedrig ist die Gefahr, dass man abgehört wird). Typischerweise können Switches mit der Zeit nicht mehr mit den neuesten TLS-Standards mehr umgehen (wird idR. bei HP und Cisco (außer vllt. bei den sehr teuren Catalysts) nachgereicht).

    Das geht soweit, dass wir in der Firma einen nicht mehr verwaltbaren Switch hatten, weil er nur SSLv3 konnte. Im Endeffekt mussten wir eine alte Firefox-Portable Version benutzen, um HTTPs wieder zu deaktivieren. Und SSLv3 wäre zu dem Zeitpunkt (nach Poodle) ebenfalls für die Katz. Klar würde man den Switch nicht in kritischen Strukturen einsetzen. Aber als VLAN-fähiger Switch für Lab oder die nächste LAN-Party ist der voll brauchbar.

    Wer Angst vor dem Abhören an der Stelle hat, kann sich übrigens auch direkt mit einem Kabel an den Switch hängen: Dann sorgt OSI-Layer 2 für „Abhörsicherheit“…

    1. Stimmt, da gibt es zum Teil Wartungslücken der Hersteller. In den letzten Jahren hat sich das aber in professionelleren Bereich bei den meisten Herstellern gebessert – zumindest bei HPE zieht man da recht zügig nach. Wer einen Switch programmieren möchte sollte aber auch in der Lage sein die Einstellungen seines Browsers bei Bedarf vorzunehmen. Ich persönlich arbeite ohnehin fast ausschleßlich per SSH – ist zwar am Anfang etwas mehr Einarbeitung, dafür hat man am Ende weniger Arbeit und kommt Schneller voran. Am Ende bleibe ich da bei meinem Motto: Wenn es nicht Verschlüsselt ist, dann ist es kaputt 😉

  3. Wie habt ihr das mit der Problematik SAN (Subject Alternate Name) auf den Switchen gelöst? Ich komme da gerade nicht wirklich weiter…

    1. Hatte ich mir am Switch nicht weiter angesehen. Bei meiner CA füge ich SAN=DNS automatisch mit ein, wenn die im CSR fehlt.

Schreibe einen Kommentar zu adlerweb Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert