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.

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.

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..

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.

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.

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.

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

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.

3 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 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.