
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
08-06-2022 01:43 PM - edited 08-06-2022 09:05 PM
Table of Contents
- Table of Contents
- Summary
- Configuration Steps
- Verification
- Certificate Signing Request Using OpenSSL
- Certificate On Switch
- Certificate Using OpenSSL
- References
Summary
Certificates are a passion of mine. enuf said.
The introduction of the Subject Alternative Name (SAN) extension in certificates was very important to the industry. This is evidenced by RFC 2818 (May 2000) stating that SAN is preferred to the common-name field, and the Certificate Authority / Browser Forum has mandated it (2016) in Section 7.1.4.2.1 of the Baseline Requirements. In March 2017 Google Chrome stopped looking at the commonName field and is only looking at the SAN field!
Subject Alternative Name is required in Certificates!
In older versions of IOS XE when configuring a Trustpoint you were able to configure a SAN using the subject-alt-name command in Trustpoint configuration mode. Unfortunately, this only worked when the IOS XE device was provisioning a Self Signed Certificate.
WELCOME to IOS XE 17.8(1)! While the Release Notes don't specify this a little-known added feature was enhancing the subject-alt-name command to introduce external CA support!
Let's see...
Configuration Steps
The configuration steps listed below ONLY create the Trustpoint and include the SAN option.
If you are interested in ALL the steps for manual Certificate Enrollment please see this document I authored.
!
configure terminal
!
crypto pki trustpoint MY-TRUSTPOINT
enrollment terminal pem
subject-name C=VI, ST=St. John, L=Saltpond Bay, O=Integrated Security Inc, OU=Tims-Lab, CN=MY-SWITCH-HOSTNAME.MYDOMAIN.NET
subject-alt-name MY-SWITCH-HOSTNAME.MYDOMAIN.NET
!
end
!
Verification
Certificate Signing Request Using OpenSSL
openssl req -noout -text
Lets view the PEM data right from the Switch. We can the output right off the Switch and paste it into OpenSSL to verify.
Now that we KNOW the SAN is populated in the Certificate Signing Request, send it to your Certificate Authority and then import the certificate into the Switch.
Certificate On Switch
show crypto pki certificates verbose TRUSTPOINT
This shows us the certificate we installed contains the x509 SAN field and that the field is populated with the FQDN we specified in our Trustpoint Config.
Certificate Using OpenSSL
openssl x509 -in CERTIFICATE-FILE-NAME.CER -text
I love using openssl for working with certificates. It's an incredibly powerful tool.
References
CA Browser Forum Baseline Requirements
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I found the way to create a CSR with SAN for versions lower than 17.8.
Create the CSR on a external server and import it.