Ich habe ein Webserver-Zertifikat aus einer CSR von meinem Cisco C9300 importiert. Das Zertifikat kam von der Zertifizierungsstelle und zeigt die richtige Zertifizierungsstelle am Ende der Kette an. Die CLI zeigt, dass das Zertifikat korrekt und ohne Probleme installiert wurde. Das Problem ist, dass ich auf die sichere Website (https://) für den Switch gehe, aber dort steht, dass die Verbindung nicht sicher ist. Ich überprüfe das Zertifikat im Browser und dort wird das Zertifikat angezeigt, das ich von der Zertifizierungsstelle erhalten habe. Warum wird dort „unsicher“ angezeigt, obwohl das Zertifikat gültig ist?
Wenn man die Seite aufruft, steht dortNET::ERR_CERT_COMMON_NAME_INVALID
UPDATE 1: Dank @Zac67 prüfe ich die Trustpoint-Informationen. Wenn wir auf den Switch für die Webseite zugreifen, verwenden wir https://ipaddress. Ich kann Folgendes erstellen:
subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=SWITCHNAME.DOMAIN.NET
Aber wenn ich subject-alt-name 192.168.1.10das mache, erhalte ich den folgenden Fehler:
CRYPTO_PKI: Label cannot be made only of digits. Also, ip addresses are not permitted
Habe versucht, die Adresse in den CN einzugeben, aber das hat auch nicht funktioniert. Es wird immer noch angezeigt, dass das Zertifikat nicht gültig ist.
UPDATE 2:Ich verwende das How-To unterHier:um einen RSA-Schlüssel zu erstellen. Mit diesem Schlüssel verwende ich meine Zertifizierungsstelle als Vertrauenspunkt. Ich erhalte den Fingerabdruck, den ich meiner Microsoft-Zertifizierungsstelle für ein Webserver-Zertifikat geben kann. Ich erhalte das Webserver-Zertifikat von meiner Zertifizierungsstelle und importiere es mit denselben Anleitungen in den Switch. Dann gehe ich auf die Webseite und dort steht, dass die Webseite ungültig ist. Das Zertifikat stammt von der Zertifizierungsstelle für meine Domäne. Ich verstehe nicht, wie diese auf die Idee kommen kann, dass es ungültig ist.
UPDATE 3:Ich schaue mir also die Vorschläge von RICK zum SAN an. Ich werde darlegen, dass wir OpenSSL nicht verwenden, da wir das nicht dürfen. WIR müssen unsere netzwerkinterne CA verwenden. Für den CN habe ich den CN auf die IP-Adresse des Zertifikats eingestellt. Für das SAN hat Cisco einen separaten Befehl, der besagt, ip-addressdass die Adresse hinzugefügt wird, und dort habe ich einen anderen Befehl subject-name-alternative, dem ich keine IP-Adresse hinzufügen kann, da dies nicht zulässig ist. Ich habe also festgestellt, dass ich Folgendes tun kann:
CN kann Folgendes sein:
- IP Adresse
- Hostname
- Vollqualifizierter Domänenname
SAN (Subject-Name-Alternative kann Folgendes sein:
- Hostname
- Vollqualifizierter Domänenname
IP-Adresse kann hinzugefügt werden oder nicht
Ich habe eine Mischung aus all diesen Dingen ausprobiert und bekomme immer noch die Meldung, dass das Zertifikat auf EDGE ungültig ist, mit dem Fehler: NET::ERR_CERT_COMMON_NAME_INVALID. Wenn ich mir das Zertifikat von Edge aus anschaue, wird dasselbe Zertifikat mit denselben Fingerabdrücken angezeigt, wenn ich es einzeln öffne.
Wie sollte also der CN lauten, wenn über Edge von der IP-Adresse darauf zugegriffen wird?
AKTUALISIERUNG 4Auch wenn ich Folgendes mache, um die CSR zu erstellen, füge ich die IP-Adresszeile hinzu. Aber wenn ich mir das Zertifikat anschaue, sieht es nicht so aus, als ob die IP-Adresse zum SAN hinzugefügt wurde.Tatsächlich enthält das Zertifikat ÜBERHAUPT KEINE SAN!Es sieht so aus, als ob bei der Übersetzung etwas verloren geht.
crypto pki trustpoint my-trustpoint
enrollment terminal pem
subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=My-Switch.my-network.com
subject-alt-name my-switch.my-network.com
serial-number none
ip-address 192.168.1.51
revocation-check none
rsakeypair my-4096rsa-key
end
Irgendeine Idee, warum die IP-Adresse nicht in das SAN aufgenommen wird?
Antwort1
Um Rickys Kommentar näher zu erläutern: Der Hostname inhttps:// mussmuss entweder mit dem Betreffnamen (SN) des Zertifikats oder einem der alternativen Betreffnamen (SAN) übereinstimmen. Wenn Sie die reine IP-Adresse verwenden, muss diese als SAN vorhanden sein. Selbst die kleinste Abweichung verursacht einen Zertifikatsfehler.
Stellen Sie außerdem sicher, dass das Stamm-CA-Zertifikat im Vertrauensspeicher des Clients vorhanden ist, wenn Sie Ihre eigene CA verwenden.
Antwort2
Wenn die von Ihnen verwendete Version von Cisco IOS die Definition eines IP-basierten Subject Alternative Name (SAN) nicht zulässt, sollten Sie die CSR mit einem anderen Tool wie OpenSSL erstellen, um die IP einzuschließen, und die CSR dann mit Ihrer Zertifizierungsstelle signieren.
Mit OpenSSL verwenden Sie eine openssl.cnfKonfigurationsdatei und hängen einen Abschnitt an, um das SAN einzuschließen (dies kann auch über die CLI erfolgen, ist aber etwas komplizierter).
Um die Konfigurationsdatei zu verwenden, [req]sollte der Abschnitt einen Parameter enthalten req_extensions, etwa wie:
req_extensions = req_ext
Der von Ihnen angegebene Wert ist der „Kontext“ für den späteren Abschnitt, der definiert, welche Erweiterungen Sie verwenden möchten. Mit req_extdiesem Wert würde der Rest der Konfiguration etwa so aussehen:
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
IP.1 = 192.168.1.10
- Um zu bestätigen, dass die generierte Zertifikatsignieranforderung (CSR) die folgenden Einträge enthält, können Sie Folgendes verwenden:
openssl req -noout -text -in switch.csr
Prüfen Sie, obX509v3 Alternativer BetreffnameAbschnitt. Darin sollten Einträge enthalten sein, IP:die alles enthalten, was Sie beim openssl.cnfGenerieren des CSR definiert haben. Wenn die IP-Adresse, die das Zertifikat sichern soll, nicht in den SAN-Einträgen des CSR aufgeführt ist, ist etwas schiefgelaufen. Bei jedem generierten Zertifikat aus einem CSR, bei dem die Felder fehlen, tritt der von Ihnen erwähnte Fehler auf, da die IP nicht richtig gesichert wird.
Wenn Sie die erwarteten IP-Einträge sehen, leiten Sie die CSR zur Signierung und Erstellung des Zertifikats an Ihre Zertifizierungsstelle weiter.
- Um zu bestätigen, dass das von der Zertifizierungsstelle signierte Zertifikat die Einträge mit einem aktuellen OpenSSL enthält, können Sie Folgendes verwenden:
openssl x509 -noout -ext subjectAltName -in switch.pem
- Um zu bestätigen, dass das von der Zertifizierungsstelle signierte Zertifikat die Einträge mit einer älteren Version von OpenSSL enthält (das Erweiterungsflag fehlt
-ext), können Sie Folgendes verwenden:
openssl x509 -noout -text -in switch.pem
Mit beiden oben genannten Methoden können Sie das signierte Zertifikat vor der Installation untersuchen. Überprüfen Sie dieAlternativer BetreffnameAbschnitte Werte. Wenn dies richtig aussieht, können Sie fortfahren und das neue Zertifikat in Ihrem Switch installieren.
Alternativ können Sie auch über den Browser die SAN-Felder auf bereits installierte Zertifikate untersuchen. Je nach Browsersoftware und -version kann die Darstellung der Informationen unterschiedlich sein.
Hier ist beispielsweise Chrome, wo Sie im Browser auf HTTPS/Sperre klicken müssen (Site-Informationen anzeigen),Verbindung ist sicherund klicken Sie dann aufZertifikat ist gültig, Ihr Schalter würde natürlich nicht gültig anzeigen, klicken Sie also aufDas Zertifikat ist ungültig.
Klicken Sie in Firefox beim Überprüfen des Zertifikats auch auf HTTPS/Lock im Browser.Sichere Verbindung(wenn natürlich wahr), dannMehr Informationen
