When doing the following to make the CSR for a certificate I add the IP Address line. But when I look at the certificate it doesn't look like the IP address is added to the SAN. In fact the certificate does not have SAN AT ALL! It looks like something is getting lost in translation.

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
revocation-check none
rsakeypair my-4096rsa-key

Has anyone else seen this or figured out how to get the SAN to show up in the certificate since something is missing with these commands?

1 Answer 1


I don't think that'll work with IOS' PKI client (which version/software generation?).



(Optional) The name argument specifies the trustpoint’s name in the Subject Alternative Name (subjectAltName) field in the X.509 certificate, which is contained in the trustpoint certificate. By default, the Subject Alternative Name field is not included in the certificate.

This option is used to create a self-signed trustpoint certificate for the router that containsthe trustpoint name in theSubject Alternative Name (subjectAltName) field. This Subject Alternative Name can be used only when the enrollment selfsigned command is specified for self-signed enrollment in the trustpoint policy

Depending on what kind of CA/PKI you run and how you run it, you might be able to set the SAN when signing the CSR (or signing the CSR, adding the SANs) then re-signing it.

Example explaining it: https://www.keyfactor.com/blog/using-an-ea-certificate-to-re-sign-csrs-to-add-correct-san-information/#:~:text=SAN%20information%20can%20be%20submitted%20within%20a%20CSR%2C%20or%20alongside%20it.

... Instead, consider using an EA certificate to re-sign CSRs while specifying correct SAN information.

Re-signing your CSRs using Certreq.exe with an enrollment agent certificate allows for the safe addition of SAN information to a CSR after its creation, but in a way that does not leave your PKI vulnerable to impersonation attacks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.