DNA. Generate CSR from GUI

[dijix1990]

I try to generate CSR through GUI - System setting -> System Certificates -> Generate new CSR, but I get error - "The common name does not contain a valid IP address or Domain Name" but maglev cluster network display shows that cluster_hostname the same common name

[pieterh]

fill in the form like this,

common name = FQDN,
SAN1=FQDN,
SAN2=short-name,
SAN3=enterprise-ip-address, or host-address (at least one SAN of type IP-address is necessary)
don't forget SAN4,5,6 for the other nodes in the cluster

[dijix1990]

Hi, I have different form - DNA last version (CN = cluster_hostname )

[pieterh]

Hmmm...
and dna.global.ftp resolves to one of the SANIP's ?
is this a single node cluster ?
else I expect four SANIP addresses in same subnet (3x node 1x cluster address)

[dijix1990]

Yes, it's single node cluster, prepared for adding second node and third node later.. And if I set vip cluster ip address as CN it works, I can generate csr... That is strange 

[pieterh]

>>> That is strange <<<
No not really.
when the cient device (switch) tries to connect to DNA (like file transfer of new image) it will do so by using the IP-address, not the cluster name, -> the VIP must be in the certificate

[dijix1990]

What do you mean? How does Web certificate refer to devices? I want to generate CSR for web 

[pieterh]

if you would use DNA's function to distribute software to switches, then DNA sends a "copy scp://<VIP>" or "copy https://<VIP>" command to the switch (https is prefered method)
for the "copy https:" method, a certificate need to be present on the DNA server that can be validated by switch that requests the file
therefore the VIP-address needs to be present in the certificate (the same certificate is also used for web management)

[Arne Bier]

I can't get this to work either - DNAC 2.3.5.4.

As @dijix1990 mentioned in his opening comments, if we use the same Common Name that DNAC put there when it generated the initial self-signed cert, then the CSR error still happens. I checked my DNS server and all the A and PTR records are in place for the nodes and the cluster - I even created a pnpserver.mydomain.com A record. 

I also tried openssl CSR creation but when I upload the CSR and Private Key, DNAC throws the same error (no valid IP or hostname in Common Name).  

The DNAC user guide says this - I tried hostname and FQDN

Has anyone found a solution to this?

OMG. When you use an IP address in the Subject Common Name (which is the most stupid thing in the world) then it works.

Cisco stuffed this up in grandiose style yet again

[dijix1990]

Yeah, it's stupid, I used as CN ip address and set in the "SAN dns" dns name for every interface

[pieterh]

look at this document:
Cisco DNA Center Security Best Practices Guide - Cisco
section : Example of openssl.cnf with IP only
describes which IP-addresses you need for a three node cluster

If I remove node#2 and #3 this would be:

DNS.1 = FQDN-of-Cisco-DNA-Center
DNS.2 = pnpserver.DomainAssignedByDHCPDuringPnP.tld
IP.1 = Enterprise port IP node #1
IP.2 = Enterprise port VIP
IP.3 = Cluster port IP node #1
IP.4 = Cluster port VIP
IP.5 = GUI port IP node #1
IP.6 = GUI port VIP
IP.7 = Cloud port IP node #1
IP.8 = Cloud port VIP

[dijix1990]

It has web gui for CSR, why we need to go through difficult way? It's a bug that's all

[Arne Bier]

I get the same error when I used openssl with a multi-SAN cert. The only time DNAC accepts it, is when the Subject Common Name is an IPv4 address. That is stupid at so many levels.

[pieterh]

Hi @Arne Bier , did you use the same hostname as in the screenshot from @dijix1990  posted10-02-2023 11:48 AM ?
is this hostname dna.global.ftp resolvable in your DNS ?

[Arne Bier]

Hello Pieter. No way - my DNAC host is not called dna.global.ftp - I think that was a made-up name anyway. The Subject is meant to be something that relates to the FQDN of the cert you're creating.

DNAC GUI has come a long way since the old days. These days, DNAC gives you a simple option of asking you the subject Name, and a few SAN entries. I gave up in the end and just used a valid IP in the Subject, and DNAC produced the CSR for me - the cert looks like this.

All of the FQDNs in the SAN are resolvable.

The joke is that when I built this lab DNAC, the self-signed cert that DNAC created for me had a Subject Common Name containing dna-cluster.rnlab.local - of course it was a self-signed cert, which prompted me to create a CSR so I could have a proper cert generated. And then landed in this mess.  But so far with IP in the Subject I have no complaints from the browser, because the SAN matches the FQDN that I put into the URL of the browser. It just looks ugly having IP addresses in the Subject (and in the SAN .. I don't know why this is a technical requirement - you don't see other vendors doing such things. And what happens in the case of IPv6?  But that's a a whole other can of worms)