Insecure Connections With CA Issue Certificate

I have imported a web server certificate from a CSR coming from my Cisco C9300. The certificate came from the Certificate authority and shows the correct CA on the end of the chain. CLI shows that the certificate was installed correctly with no problem. Issue is when I go to the Secure website (https://) for the switch but it says the connection is not secure. I check the certificate for in the browser and it shows the certificate I got from the CA. Why does it show insecure even though the certificate is valid?

When going to the page it says NET::ERR_CERT_COMMON_NAME_INVALID

UPDATE 1: Thanks to @Zac67 I am checking the Trustpoint information. When we access the switch for the web page we use https://ipaddress. I can create the following:

subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=SWITCHNAME.DOMAIN.NET

But when I do subject-alt-name 192.168.1.10 it gives me the following error:

CRYPTO_PKI: Label cannot be made only of digits. Also, ip addresses are not permitted

Tried putting the address in the CN but that didn't work either. Still says the certificate is not valid.

UPDATE 2: I am using the How-To located here: to create an RSA key. With that key I am using my CA as a trust point. I get the thumbprint to give to my Microsoft CA for a WebServer certificate. I get the WebServer certificate from my CA and import it with the same How-TO directions into the switch. I then go to the webpage and it says the webpage is not valid. The certificate is coming from the CA for my domain. I don't see how it thinks it is invalid.

UPDATE 3: So I am looking at the suggestions from RICK about the SAN. I am going to lay out we do not use OpenSSL as we are not allowed to. WE have to use our on network CA. For the CN I have set the CN to the IP address of the certificate. For the SAN Cisco has a separate commands that says ip-address which adds the address and there I have a different command called subject-name-alternative of which I can't add an IP address to that command as it is not allowed. So what I find I can do the following:

CN can be the following:

• IP address
• Hostname
• FQDN

SAN (Subject-Name-Alternative can be the following:

• Hostname
• FQDN

IP address can be added or not

Tried a mixture of all those things and it is still telling me the certificate is invalid on EDGE with the error: NET::ERR_CERT_COMMON_NAME_INVALID. If you look at the certificate from Edge it shows the same certificate if I open it on its own with the same fingerprints.

So what should the CN be when accessing it from the IP address using Edge?

UPDATE 4 Also when doing the following to make the CSR 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
ip-address 192.168.1.51
revocation-check none
rsakeypair my-4096rsa-key
end

Any idea why it isn't including the IP address into the SAN?

If the version of Cisco IOS you are using does not allow defining an IP based Subject Alternative Name (SAN) then you should create the CSR via a different tool like openssl to include the IP and then sign the CSR with your CA.

With openssl you will use an openssl.cnf configuration file and append a section to include the SAN (it can be done via CLI as well, but gets a bit more complicated).

To use the configuration file the [req] section should include a req_extensions parameter, something like:

req_extensions = req_ext

The value you provide is the "context" for the later section which defines which extensions you want to use. With req_ext as the value the rest of the configuration would look something like:

[ req_ext ]
subjectAltName = @alt_names 

[alt_names]
IP.1    = 192.168.1.10

• To confirm the generated Certificate Signing Request (CSR) contains the entries you can use:

openssl req -noout -text -in switch.csr

Check for the X509v3 Subject Alternative Name section. Inside should be entries for IP: which contain whatever you defined in the openssl.cnf when you generated the CSR. If the IP address you are expecting the certificate to secure is not listed inside the SAN entries of the CSR something went wrong, any generated certificate from a CSR missing the fields will observe the error you mentioned, as it does not secure the IP properly.

If you see the expected IP entries then pass the CSR over to your CA for signing and creation of the certificate.

• To confirm the CA signed certificate contains the entries with a recent openssl you can use:

openssl x509 -noout -ext subjectAltName -in switch.pem

• To confirm the CA signed certificate contains the entries with an older version of openssl (missing the extensions flag -ext) you can use:

openssl x509 -noout -text -in switch.pem

Using either method above you can investigate the signed certificate prior to installation. Check the Subject Alternative Name sections values. If this looks correct then go ahead and install the new certificate in your switch.

Alternatively you can also investigate SAN fields via the browser for already installed certificates. Depending on the browser software and version the layout of the information may differ.

For example here is Chrome which requires clicking on the HTTPS/Lock in the browser (view site information), clicking connection is secure then clicking Certificate is Valid, your switch would not say valid of course, so click Certificate is not valid.

Chrome: Certificate Details

In Firefox reviewing the certificate also click the HTTPS/Lock in the browser, Connection Secure (when true of course), then More Information

Firefox: View Certificate