Selbstsigniertes Zertifikat auf Brocade Switch erstellen
Moin,
wir haben mittlerweile diverse Brocade ICX64xx / ICX72xx Switche im Einsatz, die nach und nach die alten Dell Powerconnect Switche ablösen. Jetzt bin ich dabei, für alle Switche selbstsignierte Zertifikate zu erstellen und scheitere erstmal krachend, da ich nicht weiß, was ich da genau machen muss (und man mich mit dem Thema Zertifikate auch jagen kann
). Der Brocade Support, wenn auch sonst sehr hilfreich, ist in diesem Falle leider recht unbrauchbar, da kommen immer nur winzige Bröckchen an Infos. Dies machen, das machen. Ja, äh, und wie?
Unsere Umgebung: Windows Domäne mit eigener CA auf Server 2008R2, Switche wie beschrieben. Der SSL-Zugriff ist momentan über selbstsignierte Zertifikate von Brocade "abgesichert".
Alternativ könnte ich diese Zertifikate auch als vertrauenswürdig in die CA importieren?
Was ich bisher herausgefunden / gemacht habe:
- Im IIS-Manager der CA einen Request erstellt.
- Die Anforderung in der CA abgeschlossen und ein Zertifikat erstellt.
- Zertifikat im Switch importiert: (config)#ip ssl certificate-data-file tftp TFTP-SRV ZERTIFIKAT.cer
Auf den letzten Befehl kommt am Switch die Meldung: Download RSA private key file to create the certificate.
Wo kriege ich diesen Key her? Muss der an der CA erstellt werden? Wenn ja, wo sehe ich den dort? Wenn ich an der CA das neu erstellte Zertifikat importiere (Vertrauenswürdige Stammzertifizierungsstellen), kann ich es dort trotzdem nicht sehen.
Gruß
wir haben mittlerweile diverse Brocade ICX64xx / ICX72xx Switche im Einsatz, die nach und nach die alten Dell Powerconnect Switche ablösen. Jetzt bin ich dabei, für alle Switche selbstsignierte Zertifikate zu erstellen und scheitere erstmal krachend, da ich nicht weiß, was ich da genau machen muss (und man mich mit dem Thema Zertifikate auch jagen kann
). Der Brocade Support, wenn auch sonst sehr hilfreich, ist in diesem Falle leider recht unbrauchbar, da kommen immer nur winzige Bröckchen an Infos. Dies machen, das machen. Ja, äh, und wie?Unsere Umgebung: Windows Domäne mit eigener CA auf Server 2008R2, Switche wie beschrieben. Der SSL-Zugriff ist momentan über selbstsignierte Zertifikate von Brocade "abgesichert".
Alternativ könnte ich diese Zertifikate auch als vertrauenswürdig in die CA importieren?
Was ich bisher herausgefunden / gemacht habe:
- Im IIS-Manager der CA einen Request erstellt.
- Die Anforderung in der CA abgeschlossen und ein Zertifikat erstellt.
- Zertifikat im Switch importiert: (config)#ip ssl certificate-data-file tftp TFTP-SRV ZERTIFIKAT.cer
Auf den letzten Befehl kommt am Switch die Meldung: Download RSA private key file to create the certificate.
Wo kriege ich diesen Key her? Muss der an der CA erstellt werden? Wenn ja, wo sehe ich den dort? Wenn ich an der CA das neu erstellte Zertifikat importiere (Vertrauenswürdige Stammzertifizierungsstellen), kann ich es dort trotzdem nicht sehen.
Gruß
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329745
Url: https://administrator.de/forum/selbstsigniertes-zertifikat-auf-brocade-switch-erstellen-329745.html
Ausgedruckt am: 26.04.2025 um 00:04 Uhr
10 Kommentare
Neuester Kommentar
Ganz vergessen... Das RSA Schlüsselpaar auf dem Switch habe ich auch erzeugt.
Mmmhhh, eigentlich ist das nicht schwer.
Key Datei erstellen und auf den Flash Speicher kopieren:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
bzw.
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
AAA Authentication auf local setzen und das wars:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
Lesenswert dazu auch:
https://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernet ...
Die selbstgenerierten Keys wirst du vermutlich wieder löschen müssen wenn du den Keyfile auf den Switch geflasht hast.
Key Datei erstellen und auf den Flash Speicher kopieren:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
bzw.
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
AAA Authentication auf local setzen und das wars:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
Lesenswert dazu auch:
https://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernet ...
Die selbstgenerierten Keys wirst du vermutlich wieder löschen müssen wenn du den Keyfile auf den Switch geflasht hast.
Hi Aqui,
auf Dich habe ich gehofft
Danke für die Links!
Zu dem Thema:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
Der öffentliche Schlüssel von jedem Client... Da wir eine Windows-CA haben, müsste ja der Import des CA-Zertifikates samt privatem Schlüssel in den Switch ausreichen?
Damit sind wir schon beim nächsten Punkt, wenn ich das Zertifikat importiere, klappt das scheinbar auch. Der Import des privaten Schlüssels schlägt fehl mit der Meldung
Cert import failed....Could not parse the PEM-encoded import data
Der letzte Link ist wirklich sehr interessant, vielen Dank!
Gruß
auf Dich habe ich gehofft
Danke für die Links!
Zu dem Thema:
http://www.brocade.com/content/html/en/configuration-guide/fastiron-080 ...
Der öffentliche Schlüssel von jedem Client... Da wir eine Windows-CA haben, müsste ja der Import des CA-Zertifikates samt privatem Schlüssel in den Switch ausreichen?
Damit sind wir schon beim nächsten Punkt, wenn ich das Zertifikat importiere, klappt das scheinbar auch. Der Import des privaten Schlüssels schlägt fehl mit der Meldung
Cert import failed....Could not parse the PEM-encoded import data
Der letzte Link ist wirklich sehr interessant, vielen Dank!
Gruß
Ich habe das bis jetzt noch nicht mit einem Windows gemacht sondern immer ssh-keygen oder das PuTTY Tool puttygen.exe benutzt.
Damit ist es eigentlich recht einfach und schnell gemacht.
ssh-keygen oder puttygen erzeugen immer zwei Schlüsseldateien, einem privaten und einem öffentlichen Teil. Der private verbleibt auf dem Rechner, der die Verbindungen aufbaut.
Der öffentliche kommt auf den Switch oder z.B. bei einem Linux Host in die .authorized_keys Datei auf dem Rechner.
Bei Linux recht es die /etc/ssh/ sshd_config zu editieren und das Anmelden per Passwort ganz abzuschalten: PasswordAuthentication no und Challenge- ResponseAuthentication no setzen in der Datei.
Ein Linux SSH-Server lässt dann nur noch Benutzer rein, die einen SSH- Schlüssel vorweisen können, der in einer .authorized_keys-Datei hinterlegt ist wie oben beschrieben.
Das ist im Switch alles schon per Default aktiviert. Sowie der Schlüssel auf dem internen Flash kopiert ist prüft er dagegen.
Das hat bis jetzt bei Cisco, Brocade, Extreme und sogar Billigheime HP funktioniert
Damit ist es eigentlich recht einfach und schnell gemacht.
ssh-keygen oder puttygen erzeugen immer zwei Schlüsseldateien, einem privaten und einem öffentlichen Teil. Der private verbleibt auf dem Rechner, der die Verbindungen aufbaut.
Der öffentliche kommt auf den Switch oder z.B. bei einem Linux Host in die .authorized_keys Datei auf dem Rechner.
Bei Linux recht es die /etc/ssh/ sshd_config zu editieren und das Anmelden per Passwort ganz abzuschalten: PasswordAuthentication no und Challenge- ResponseAuthentication no setzen in der Datei.
Ein Linux SSH-Server lässt dann nur noch Benutzer rein, die einen SSH- Schlüssel vorweisen können, der in einer .authorized_keys-Datei hinterlegt ist wie oben beschrieben.
Das ist im Switch alles schon per Default aktiviert. Sowie der Schlüssel auf dem internen Flash kopiert ist prüft er dagegen.
Das hat bis jetzt bei Cisco, Brocade, Extreme und sogar Billigheime HP funktioniert
Ja, würde auch klappen, aber securitytechnisch würde ich rechnerbezogen gar nicht so weit gehen wollen, das Einflippern in die CA würde mir ja schon reichen. Dafür bin ich noch zu wenig paranoid, um das für jeden Rechner umzusetzen, der Zugriff haben soll
Schöne Sache, der Supporter hat auch nicht so richtig Plan, ich warte noch mal auf meinen deutschen Brocade-Kontakt, vielleicht kann der mir helfen. Ansonsten würde ich direkt auf dem Switch ein Zertifikat erstellen und das dann in die CA exportieren, dummerweise verschlüsselt der Switch dann nur mit SHA1, was wiederum zu bekannter Browsermeckerei führt (sofern ich nicht den IE oder Edge nehme, denen ist ja so ziemlich alles egal).
Leider habe ich bislang keine Möglichkeit gefunden, den Switch zu SHA2 zu überreden.
Was ich noch erfolglos versucht habe:
- Import von Zertifikat und Schlüssel als .txt --> Bringt auch nix, selber Fehler
- Zwischendrin den Zertfikatspeicher auf dem Switch gelöscht und erneut den Import versucht --> Nix
Schöne Sache, der Supporter hat auch nicht so richtig Plan, ich warte noch mal auf meinen deutschen Brocade-Kontakt, vielleicht kann der mir helfen. Ansonsten würde ich direkt auf dem Switch ein Zertifikat erstellen und das dann in die CA exportieren, dummerweise verschlüsselt der Switch dann nur mit SHA1, was wiederum zu bekannter Browsermeckerei führt (sofern ich nicht den IE oder Edge nehme, denen ist ja so ziemlich alles egal
).Leider habe ich bislang keine Möglichkeit gefunden, den Switch zu SHA2 zu überreden.
Was ich noch erfolglos versucht habe:
- Import von Zertifikat und Schlüssel als .txt --> Bringt auch nix, selber Fehler
- Zwischendrin den Zertfikatspeicher auf dem Switch gelöscht und erneut den Import versucht --> Nix
Ansonsten würde ich direkt auf dem Switch ein Zertifikat erstellen und das dann in die CA exportieren,
Nein, das wäre ja komplett der falsche Weg !Du hast es ja richtig gemacht. Mit dem CA die Keys erzeugt. Der private bleibt auf dem Rechner oder wird via Windows AD an die Clients verteilt und der öffentliche gehört via TFTP kopiert aufs lokale Flash aller deiner Switches.
Fertig....
Nichts anderes ist ja oben gemacht nur das das keypaar eben mit einer anderen SW erstellt wurde.
Den Switch schaltest du dann im AAA auf login local und das wars.
Hat hier immer funktioniert.
Aber setz dich in Verbindung mit deinem lokalen Brocade SE in der Region, der kann dir in jedem Falle auch mit internen Tutorials helfen !
Funktionieren tut das ganz sicher.
Moin,
kurze Statusmeldung
AAA steht schon auf login local.
Was ich gemacht habe:
- Um sicherzugehen, lösche ich auf dem Switch alle Zertifikate: crypto-ssl certificate zeroize
- Schreiben in die Startkonfig: write memory
- Paranoid-Modus, damit alles sauber ist: reload
- Erstellung der Zertifikatanforderung mit Microsoft IIS auf dem CA-Server
- Erstellung des Zertifikats mit certreq -attrib "CertificateTemplate:webserver" -submit PFAD\ANFORDERUNG.csr
- Speichern des Zertifikats und Installation in der CA (Vertrauenswürdige Stammzertifizierungsstellen)
- Export mitsamt privatem Schlüssel in .pfx-Datei (Haken bei "Wenn möglich, alle Zertifikate im Zertfizierungspfad einbeziehen")
- Bearbeitung des exportierten .pfx mit OpenSSL
- Run the following command to export the private key: openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes
- Run the following command to export the certificate: openssl pkcs12 -in certname.pfx -nokeys -out cert.pem
- Run the following command to remove the passphrase from the private key: openssl rsa -in key.pem -out server.key
- Import des Zertifikats auf dem Switch: ip ssl certificate-data-file tftp 192.168.9.210 certfile
- Meldung auf Switch: Download RSA private key file to create the certificate.
- Import des privaten Schlüssels auf Switch: ip ssl private-key-file tftp 192.168.9.210 keyfile
- Fehlermeldung:
Creating certificate, please wait...
Cert import failed....Could not parse the PEM-encoded import data
Certificate creation status - failed
Und das war's... Lustigerweise kann ich auf die beschriebene Art das Stammzertifikat der CA so auf dem Switch installieren, aber das nutzt mir ja nix...
Der lokale SE kümmert sich parallel, vielleicht fällt Dir ja etwas auf?
Gruß
kurze Statusmeldung
AAA steht schon auf login local.
Was ich gemacht habe:
- Um sicherzugehen, lösche ich auf dem Switch alle Zertifikate: crypto-ssl certificate zeroize
- Schreiben in die Startkonfig: write memory
- Paranoid-Modus, damit alles sauber ist: reload
- Erstellung der Zertifikatanforderung mit Microsoft IIS auf dem CA-Server
- Erstellung des Zertifikats mit certreq -attrib "CertificateTemplate:webserver" -submit PFAD\ANFORDERUNG.csr
- Speichern des Zertifikats und Installation in der CA (Vertrauenswürdige Stammzertifizierungsstellen)
- Export mitsamt privatem Schlüssel in .pfx-Datei (Haken bei "Wenn möglich, alle Zertifikate im Zertfizierungspfad einbeziehen")
- Bearbeitung des exportierten .pfx mit OpenSSL
- Run the following command to export the private key: openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes
- Run the following command to export the certificate: openssl pkcs12 -in certname.pfx -nokeys -out cert.pem
- Run the following command to remove the passphrase from the private key: openssl rsa -in key.pem -out server.key
- Import des Zertifikats auf dem Switch: ip ssl certificate-data-file tftp 192.168.9.210 certfile
- Meldung auf Switch: Download RSA private key file to create the certificate.
- Import des privaten Schlüssels auf Switch: ip ssl private-key-file tftp 192.168.9.210 keyfile
- Fehlermeldung:
Creating certificate, please wait...
Cert import failed....Could not parse the PEM-encoded import data
Certificate creation status - failed
Und das war's... Lustigerweise kann ich auf die beschriebene Art das Stammzertifikat der CA so auf dem Switch installieren, aber das nutzt mir ja nix...
Der lokale SE kümmert sich parallel, vielleicht fällt Dir ja etwas auf?
Gruß
Mmmhhh...das sieht soweit alles sehr schlüssig aus und wäre auch der richtige Weg.
Es sieht aber final so aus als ob der Switch das exportierte Key Format nicht versteht. Wie gesagt ich hatte das immer mit PuTTYgen probiert und da klappte es.
Vielleicht wäre das parallel nochmal einen Test wert nur um zu sehen ob er das Format lesen kann beim Einbinden.
Was ich aber generell nicht verstehe ist warum du den privaten Schlüssel auf dem Switch installierst. Das dürfte eigentlich niemals so sein !
Das Vorgehen ist ja exakt so wie beim SSH Zugriff mit Key bei Linux. Auf dem Device selber (Linux Host, Switch, Router etc.) auf das zugegriffen wird ist immer nur der öffentliche Schlüssel, niemals aber der Private. Ich habe von PuTTYgen immer nur den öffentlichen importiert.
Der Private bleibt einzig auf dem Rechner mit dem man zugreift.
Das ist bei dir etwas verwirrend und ggf. liegt da der Fehler ?
Wenn es das nicht ist solltest du in jedem Falle auch parallel mal einen Support Case in deren TAC eröffnen. Support ist ja beim Switch mit dabei
Es sieht aber final so aus als ob der Switch das exportierte Key Format nicht versteht. Wie gesagt ich hatte das immer mit PuTTYgen probiert und da klappte es.
Vielleicht wäre das parallel nochmal einen Test wert nur um zu sehen ob er das Format lesen kann beim Einbinden.
Was ich aber generell nicht verstehe ist warum du den privaten Schlüssel auf dem Switch installierst. Das dürfte eigentlich niemals so sein !
Das Vorgehen ist ja exakt so wie beim SSH Zugriff mit Key bei Linux. Auf dem Device selber (Linux Host, Switch, Router etc.) auf das zugegriffen wird ist immer nur der öffentliche Schlüssel, niemals aber der Private. Ich habe von PuTTYgen immer nur den öffentlichen importiert.
Der Private bleibt einzig auf dem Rechner mit dem man zugreift.
Das ist bei dir etwas verwirrend und ggf. liegt da der Fehler ?
Wenn es das nicht ist solltest du in jedem Falle auch parallel mal einen Support Case in deren TAC eröffnen. Support ist ja beim Switch mit dabei
Nach langer Zeit mal ein Update...
Funktioniert immer noch nicht, nach langem Hin und Her sagt Brocade jetzt, dass das ein Firmwareproblem ist: Unsere CA verschlüsselt mit SHA2, der Switch kann aber nur SHA1 verwursten. Am 15.5. soll es ein Firmwareupdate geben, das das Problem löst. Warten wir mal ab...
Funktioniert immer noch nicht, nach langem Hin und Her sagt Brocade jetzt, dass das ein Firmwareproblem ist: Unsere CA verschlüsselt mit SHA2, der Switch kann aber nur SHA1 verwursten. Am 15.5. soll es ein Firmwareupdate geben, das das Problem löst. Warten wir mal ab...
Danke für das Feedback.
OK, das ist dann klar das das fehlschlägt wenn die SHAs unterschiedlich sind.
Dann machen wir hier im Mai mal weiter nach dem Motto Alles neu macht der Mai ! Es bleibt also spannend.
Schreib mal obs dann rennt oder nicht das wäre schon interessant.
OK, das ist dann klar das das fehlschlägt wenn die SHAs unterschiedlich sind.
Dann machen wir hier im Mai mal weiter nach dem Motto Alles neu macht der Mai !
Es bleibt also spannend.Schreib mal obs dann rennt oder nicht das wäre schon interessant.
