Input
$ maglev cluster network display
Output
cluster_network:
	cluster_dns: 169.254.20.10
	cluster_hostname: fqdn.cisco.com

If the cluster_hostname output field is empty or is not what you want, add or change the Cisco DNA Center hostname (FQDN) by entering the sudo maglev-config update command, as shown in the following example. You must have root privileges to run this command.

Input
$ sudo maglev-config update
Output
Maglev config wizard GUI

Click Next until you see the step titled MAGLEV CLUSTER DETAILS containing the input prompt Cluster's hostname. Set the hostname to the desired Cisco DNA Center FQDN. Click Next and Proceed until Cisco DNA Center is reconfigured with the new FQDN.

• Adjust default_bits and default_md if your certificate authority admin team requires 2048/sha256 instead.

• Specify values for every field in the req_distinguished_name and alt_names sections. The only exception is the OU field, which is optional. Omit the OU field if your certificate authority admin team does not require it.

• The emailAddress field is optional; omit it if your certificate authority admin team does not require it.

• alt_names section: The certificate configuration requirements vary depending on the Cisco DNA Center version.

  Limited support of FQDNs in the Cisco DNA Center certificate is available from Cisco DNA Center 2.1.1 onwards. However, FQDN support in the Cisco DNA Center certificate is not currently available for LAN automation. If you plan to use LAN automation, you cannot use an FQDN-only certificate (even from Cisco DNA Center 2.1.1 onwards).

  For Cisco DNA Center versions earlier than 2.1.1 (and if you plan to use LAN automation in Cisco DNA Center versions 2.1.1 and later), you need a certificate with IP addresses defined in the Subject Alternative Name (SAN) field. See, Cisco DNA Center versions earlier than 2.1.1, and Cisco DNA Center versions 2.1.1 onwards if you plan to use LAN automation bullet point mentioned below for guidance regarding the alt_names section in this scenario.

  The alt_names section configurations for Cisco DNA Center versions 2.1.1 and later (without LAN automation support) are as follows.

  Note

  For security reasons, we recommend that you only use FQDNs in the Cisco DNA Center certificate (limited FQDN support is available from Cisco DNA Center 2.1.1 onwards without LAN automation). If you want to use IP addresses instead of FQDNs in the certificate (or need to because you are using LAN automation), complete the steps described in the Cisco DNA Center versions earlier than 2.1.1, and Cisco DNA Center versions 2.1.1 onwards if you plan to use LAN automation bullet point, ensuring that you enter IP addresses in the SAN fields.

  • Cisco DNA Center versions 2.1.1 and later (without LAN automation support):

    Pay close attention to the alt_names section, which must contain all DNS names (including the Cisco DNA Center FQDN) that are used to access Cisco DNA Center, either by a web browser or by an automated process such as PnP or Cisco ISE.

    The first DNS entry in the alt_names section should contain Cisco DNA Center's FQDN (DNS.1 = FQDN-of-Cisco-DNA-Center). You cannot add a wildcard DNS entry in place of Cisco DNA Center's FQDN, but you can use a wildcard in subsequent DNS entries in the alt-names section (for PnP and other DNS entries). For example, *.domain.com is a valid entry.

    Important

    For Cisco DNA Center 2.1.1 and later, FQDN support is not available for LAN automation. For Cisco DNA Center 2.1.1 and later, if the certificate only contains FQDNs, the DHCP pool on the seed device needs to be edited in order for PnP to work. For guidance, see the following information in Cisco DNA Center User Guide's "Provision Your Network" chapter: PnP: At the end of the "DHCP Controller Discovery" topic, see the information that begins with the following text: "If the Cisco DNA Center system certificate has an FQDN-only SAN field....

  • The alt_names section must contain FQDN-of-Cisco-DNA-Center as a DNS entry, and must match the Cisco DNA Center hostname (FQDN) that is set during Cisco DNA Center configuration through the configuration wizard (in the Cluster's hostname input field).

    Cisco DNA Center currently supports only one hostname (FQDN) for all interfaces. If you are using both the management port and the enterprise port in Cisco DNA Center to connect devices to Cisco DNA Center in your network, you must configure the GeoDNS policy such that it resolves to the management IP or virtual IP and enterprise IP/virtual IP for the Cisco DNA Center hostname (FQDN) based on the network from which the DNS query is received. Setting up a GeoDNS policy is not required if you are using only the enterprise port in Cisco DNA Center to connect devices to Cisco DNA Center in your network.

    Note	If you have enabled disaster recovery for Cisco DNA Center:

    • If you are using virtual IPs for Disaster Recovery, you must use the same cluster_hostname, that is, the FQDN for Cisco DNA Center (set in Cisco DNA Center configuration wizard), in both main and recovery clusters. Also, you must configure the GeoDNS policy such that it resolves the disaster recovery management virtual IP and the disaster recovery enterprise virtual IP for the Cisco DNA Center hostname (FQDN), based on the network from which the DNS query is received. Setting up a GeoDNS policy is only required if you are using both the management port and the enterprise port in Cisco DNA Center to connect devices to Cisco DNA Center in your network. Certificate alt_names sections look similar to the following::

      [alt_names]
      DNS.1 = FQDN-of-Cisco-DNA-Center

    • If you are not using virtual IPs for Disaster Recovery, you must use different cluster_hostnames, that is the FQDNs for Cisco DNA Center in an enterprise network (set in Cisco DNA Center configuration wizard), in both the main and recovery clusters. Also, you must configure a GeoDNS policy such that it resolves the disaster recovery management IP and the disaster recovery enterprise IP for the Cisco DNA Center hostname (FQDN) based on the network from which the DNS query is received, for both the main and recovery clusters. Setting up a GeoDNS policy is only required if you are using both the management and the enterprise port in Cisco DNA Center for connecting devices to Cisco DNA Center in your network. Certificate alt_names sections look similar to the following:

      [alt_names]
      DNS.1 = FQDN-of-Cisco-DNA-Center-Main
      DNS.2 = FQDN-of-Cisco-DNA-Center-Recovery
      

    For more information, see "Implement Disaster Recovery Certificate" in the Cisco DNA Center Administrator Guide.

  • Cisco DNA Center versions earlier than 2.1.1, and Cisco DNA Center versions 2.1.1 onwards if you plan to use LAN automation:

    Pay close attention to the alt_names section, which must contain all the IP addresses and DNS names that are used to access Cisco DNA Center, either by a web browser or by an automated process such as PnP or Cisco ISE. (The following example assumes a three-node Cisco DNA Center cluster. If you have a standalone device, use SANs for only that node and the VIP. If you cluster the device later, you might want to re-create the certificate to include the IP addresses of the new cluster members.)

• If a cloud interface is not configured, omit the cloud port fields:

  • In the extendedKeyUsage extension, the attributes serverAuth and clientAuth are mandatory. If you omit either attribute, Cisco DNA Center rejects the SSL certificate.

  • If you are importing a self-signed certificate (not recommended), it must contain the X.509 Basic Constraints "CA:TRUE" extension, and the keyUsage extension must include keyCertSign.

Example of openssl.cnf (applicable for Cisco DNA Center versions 2.1.1 and later, without LAN automation support)

req_extensions = v3_req
distinguished_name = req_distinguished_name
default_bits = 4096
default_md = sha512
prompt = no
[req_distinguished_name]
C = <two-letter-country-code>
ST = <state-or-province>
L = <city>
O = <company-name>
OU = MyDivision
CN = FQDN-of-Cisco-DNA-Center
emailAddress = responsible-user@mycompany.tld

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = FQDN-of-Cisco-DNA-Center
DNS.2 = pnpserver.DomainAssignedByDHCPDuringPnP.tld
DNS.3 = *.domain.com

Example of openssl.cnf (applicable for Cisco DNA Center versions earlier than 2.1.1, and Cisco DNA Center versions 2.1.1 onwards if you plan to use LAN automation)

req_extensions = v3_req
distinguished_name = req_distinguished_name
default_bits = 4096
default_md = sha512
prompt = no
[req_distinguished_name]
C = <two-letter-country-code>
ST = <state-or-province>
L = <city> O = <company-name>
OU = MyDivision
CN = FQDN-of-Cisco-DNA-Center
emailAddress = responsible-user@mycompany.tld
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = FQDN-of-Cisco-DNA-Center
DNS.2 = pnpserver.DomainAssignedByDHCPDuringPnP.tld
IP.1 = Enterprise port IP node #1
IP.2 = Enterprise port IP node #2
IP.3 = Enterprise port IP node #3
IP.4 = Enterprise port VIP
IP.5 = Cluster port IP node #1
IP.6 = Cluster port IP node #2
IP.7 = Cluster port IP node #3
IP.8 = Cluster port VIP
IP.9 = GUI port IP node #1
IP.10 = GUI port IP node #2
IP.11 = GUI port IP node #3
IP.12 = GUI port VIP
IP.13 = Cloud port IP node #1
IP.14 = Cloud port IP node #2
IP.15 = Cloud port IP node #3
IP.16 = Cloud port VIP

openssl genrsa -out csr.key 4096

openssl req -config openssl.cnf -new -key csr.key -out DNAC.csr 

openssl req -text -noout -verify -in DNAC.csr

Ensure that the certificate template you choose is configured for both client and server authentication (as illustrated in the extendedKeyUsage line in Step 2's openssl.cnf file example).

When you first view this window, the current certificate data that is displayed is the Cisco DNA Center self-signed certificate. The self-signed certificate's expiry is set for several years in the future.

The System tab displays the following fields:

• Current Certificate Name: Name of the current certificate.

• Issuer: Name of the entity that has signed and issued the certificate.

• Authority: Either self-signed or the name of the CA.

• Expires: Expiry date of the certificate.

In Cisco DNA Center 2.3.2 and later, you will see the Generate New CSR link if you are generating the CSR for the first time. Otherwise, you will see the Download existing CSR link. You can download the existing CSR and submit it to your provider to generate your certificate. If you don't want to use the existing CSR, click Delete existing CSR and click Accept in the subsequent Confirmation window. You can now see the Generate New CSR link.

The generated new CSR is downloaded automatically.

The Certificate Signing window shows the CSR properties and allows you to do the following:

• Copy the CSR properties in plain text.

• Copy Base64 and paste to MS CA.

• Download Base64.

• PEM: Privacy-enhanced mail file format.

• PKCS: Public-Key Cryptography Standard file format.

  Note	PKCS file type is disabled if you choose the Generate New CSR option to request a certificate.

• Import the PEM file by dragging and dropping the file into the Drag and Drop area.

  Note	A PEM file must have a valid PEM format extension (.pem). The maximum file size for the certificate is 10 MB. After the upload succeeds, the system certificate is validated.

• Import the Private Key by dragging and dropping the file into the Drag and Drop area.

  Note	Private keys must have a valid private key format extension (.key). The maximum file size for the private key is 10 MB. After the upload succeeds, the private key is validated.

  • Choose the encryption option from the Encrypted area for the private key.

  • If you choose encryption, enter the password for the private key in the Password field.

• Import the PKCS file by dragging and dropping the file into the Drag and Drop area.

  Note	A PKCS file must have a valid PKCS format extension (.pfx or .p12). The maximum file size for the certificate is 10 MB. After the upload succeeds, the system certificate is validated.

• Enter the passphrase for the certificate in the Password field.

  Note	For PKCS, the imported certificate also requires a passphrase.

• For the Private Key field, choose the encryption option for the private key.

• For the Private Key field, if encryption is chosen, enter the password for the private key in the Password field.

• Root CA Certificate: Displays the current root CA certificate (either external or internal).

• Root CA Certificate Lifetime: Displays the current lifetime value of the current root CA certificate, in days.

• Current CA Mode: Displays the current CA mode (root CA or subordinate CA).

• Sub CA Mode: Enables a change from a root CA to a subordinate CA.

For example,

• Changing from root CA to subordinate CA is a process that cannot be reversed.

• You must ensure that no network devices have been enrolled or issued a certificate in root CA mode. Network devices that have been accidentally enrolled in root CA mode must be revoked before changing from root CA to subordinate CA.

• Network devices must come online only after the subordinate CA configuration process finishes.

The PKI Certificate Management window displays the Import External Root CA Certificate field.

The root CA certificate is uploaded into Cisco DNA Center and used to generate a Certificate Signing Request.

After the upload process finishes, a Certificate Uploaded Successfully message is displayed.

Cisco DNA Center generates and displays the Certificate Signing Request.

• Click the Download link to download a local copy of the Certificate Signing Request file.

  You can then attach this Certificate Signing Request file to an email to send to your root CA.

• Click the Copy to the Clipboard link to copy the Certificate Signing Request file's content.

  You can then paste this Certificate Signing Request content to an email or include it as an attachment to an email and send it to your root CA.

Your root CA will then return a subordinate CA file, which you must import back into Cisco DNA Center.

After clicking Yes, the GUI view with the Certificate Signing Request is displayed.

The PKI Certificate Management window displays the Import Sub CA Certificate field.

The subordinate CA certificate is uploaded into Cisco DNA Center.

After the upload finishes, the GUI displays the subordinate CA mode under the CA Management tab.

• Sub CA Certificate: Displays the current subordinate CA certificate.

• External Root CA Certificate: Displays the root CA certificate.

• Sub CA Certificate Lifetime: Displays the lifetime value of the subordinate CA certificate, in days.

• Current CA Mode: Displays SubCA mode.

• Subordinate CA Certificate: Displays the current subordinate CA certificate.

• External Root CA Certificate: Displays the root CA certificate.

• Subordinate CA Certificate Lifetime: Displays the lifetime value of the current subordinate CA certificate, in days.

• Current CA Mode: Displays SubCA mode.

Cisco DNA Center uses the existing subordinate CA to generate and display the rollover subordinate CA Certificate Signing Request.

• Click the Download link to download a local copy of the Certificate Signing Request file.

  You can then attach this Certificate Signing Request file to an email to send it to your root CA.

• Click the Copy to the Clipboard link to copy the content of the Certificate Signing Request file.

  You can then paste this Certificate Signing Request content to an email or include it as an attachment to an email and send it to your root CA.

Your root CA will then return a rollover subordinate CA file that you must import back into Cisco DNA Center.

The Certificate Signing Request for the subordinate CA rollover must be signed by the same root CA who signed the subordinate CA you imported when you switched from RootCA mode to SubCA mode.

The PKI Certificate Management window displays the Import Sub CA Certificate field.

The rollover subordinate CA certificate is uploaded into Cisco DNA Center.

After the upload finishes, the GUI changes to disable the Renew button under the CA Management tab.

The PnP server logs show that the device moves from the CERTIFICATE_INSTALL_REQUESTED stage to the FILESYSTEM_INFO_REQUESTED stage, but no further progress is made. For example:

2018-11-28 12:05:40,711 |   INFO | qtp226594800-88458        |  | com.cisco.enc.pnp.state.ZtdState | 
Device state has changed from CERTIFICATE_INSTALL_REQUESTED to FILESYSTEM_INFO_REQUESTED | 
sn=SOME_SN, address=SOME_IP

Thereafter, PnP provisioning fails with an error that is similar to the following:

2018-11-28 12:25:56,289 |  ERROR | eHealthCheckFirstBucket-2 |  | c.c.e.z.impl.ZtdHistoryServiceImpl | 
Failed health check since device is stuck in non-terminal state FILESYSTEM_INFO_REQUESTED for more than threshold time: 
0 hours, 16 minutes, 0 seconds | sn=SOME_SN

debug crypto pki val
debug crypto pki api
debug crypto pki call
debug crypto pki tr
debug ssl openssl error
debug ssl openssl msg
debug ssl openssl state
debug ssl openssl ext

show crypto pki certificate
show running
show pnp tech

echo | openssl s_client -showcerts -servername SERVER_IP -connect 
SERVER_IP:443 2>/dev/null | openssl x509 -inform pem -noout -text

The output is similar to the following:

[username@toolkit ~]$ echo | openssl s_client -showcerts -servername SERVER_IP -connect 
SERVER_IP:443 2>/dev/null | openssl x509 -inform pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:92:63:49:41:36:99:43:00:57:43:86:06:10:44:57:32:48:65:00
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=e328c7fc-3495-4bc1-81a4-66a31d0507f6, C=US, ST=California, L=SanJose, OU=DNAC, O=Cisco
        Validity
            Not Before: Aug 24 05:55:29 2017 GMT
            Not After : Aug 23 05:55:29 2022 GMT
        Subject: CN=SERVER_IP, ST=California, C=US, O=Cisco, OU=DNAC
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a2:21:ba:52:b4:9e:50:02:c0:68:2e:b3:43:0a:
                    <snip>
                    9e:1b:ef:19:96:f9:2b:e3:6a:58:05:b3:c5:b3:d3:
                    24:ab
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                IP Address:SERVER_IP

• If you are using a signed certificate, generate a new Certificate Signing Request that is signed by the CA, including the appropriate SAN field. See Update the Cisco DNA Center Server Certificate.

• If you are using a self-signed certificate (not recommended), see Generate a Certificate Request Using Open SSL.

The Audit Logs window opens, where you can view logs about the current policies in your network. These policies are applied to network devices by the applications installed on Cisco DNA Center.

1. In the Time Range area, choose a time range—Last 2 Weeks, Last 7 Days, Last 24 Hours, or Last 3 Hours.

2. To specify a custom range, click By Date and specify the start and end date and time.

3. Click Apply.

Each audit log can be a parent to several child audit logs. By clicking the arrow, you can view a series of additional child audit logs.

The audit log displays the Description, User, Interface, and Destination of each policy in the right pane.

A list of syslog servers is displayed.