Managing TLS Certificate, KeyStore, and TrustStore Files

This chapter contains the following sections:

About the TLS Certificate, KeyStore, and TrustStore Files


Note

When Cisco Nexus Data Broker is started in a normal way, the connection to the device is HTTP. When Cisco Nexus Data Broker is started using the TLS protocol, the connection to the device is in HTTPS.


Note

To configure High Availability clusters in TLS mode, you need to run Cisco Nexus Data Broker in TLS mode for each instance of Cisco Nexus Data Broker.

Cisco Nexus Series switches connecting to Cisco Nexus Data Broker over OpenFlow require additional credentials, including Private Key, Certificate, and Certificate Authority (CA).

  • The TLS TrustStore file contains the Certification Authority (CA) certificates used to sign the certificates on the connecting switches.

Preparing to Generate the TLS Credentials

OpenFlow switches require cryptographic configuration to enable TLS.

The NX-API protocol plugin now supports TLS for secure communication to the devices. You can connect to the NX-API protocol plugin on the secure port 443. All configuration, discovery, and statistics collection is done using secure communication. Cisco Nexus Data Broker should be configured with the required certificates and it should be started in the secure mode. When Cisco Nexus Data Broker is started in TLS mode, all devices support the TLS connection. The normal unencrypted connection to the switches is not accepted.


Caution

Self-signed certificates are appropriate only for test environment. For security and granular controls over individual certificate use and revocation, you should use certificates generated by your organization's Certificate Authority. The self-signed certificate do not provide any security in production environment and NXAPI web interface will display as Not Secure.

Before you begin

Ensure that OpenSSL is installed on the Linux host where these steps will be performed.

Procedure

Step 1

Create a TLS directory using mkdir -p TLS command and then navigate to it using cd TLS command:

mkdir -p TLS

cd TLS

Step 2

Set up the directories for your CA system to function within. Create three directories under mypersonalca using mkdir -p mypersonalca/<directory name> command. To initialize the serial file and the index.txt file, enter echo "01" > mypersonalca/serial command and touch mypersonalca/index.txt command respectively.

mkdir -p mypersonalca/certs

mkdir -p mypersonalca/private

mkdir -p mypersonalca/crl

echo "01" > mypersonalca/serial

touch mypersonalca/index.txt

The serial file and the index.txt file are used by the CA to maintain its database of the certificate files.

Step 3

Create the CA configuration file (ca.conf). Before saving the ca.cnf file, some changes need to be made that are specific to the devices. One critical change is to change the [alt_names] section in the ca.conf file to be relevant to the device IP address, because these IP addresses should be specified in the configuration file. If you need more or fewer IP/DNS names, you can add or remove the lines.

Note 

This step is applicable to NX-API only.

The following is an example of the content of the ca.conf file: 

[ ca ]
default_ca              = CA_default
 
 
[ CA_default ]
dir                     = .
serial                  = $dir/serial
database                = $dir/index.txt
new_certs_dir           = $dir/newcerts
certs                   = $dir/certs
certificate             = $certs/cacert.pem
private_key             = $dir/private/cakey.pem
default_days            = 365
default_md              = sha1
preserve                = no
email_in_dn             = no
nameopt                 = default_ca
certopt                 = default_ca
policy                  = policy_match
copy_extensions         = copy
 
 
[ policy_match ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
 
 
 
[ req ]
default_bits            = 2048                  # Size of keys
default_keyfile         = example.key           # name of generated keys
default_md              = sha1                  # message digest algorithm
string_mask             = nombstr               # permitted characters
distinguished_name      = req_distinguished_name
req_extensions          = v3_req
x509_extensions         = v3_req
 
 
[ req_distinguished_name ]
# Variable name           Prompt string
#----------------------   ----------------------------------
0.organizationName      = Organization Name (company)
organizationalUnitName  = Organizational Unit Name (department, division)
emailAddress            = Email Address
emailAddress_max        = 40
localityName            = Locality Name (city, district)
stateOrProvinceName     = State or Province Name (full name)
countryName             = Country Name (2 letter code)
countryName_min         = 2
countryName_max         = 2
commonName              = Common Name (hostname, IP, or your name)
commonName_max          = 64
 
 
# Default values for the above, for consistency and less typing.
# Variable name                   Value
#------------------------------   ------------------------------
commonName_default              = www.cisco.com
0.organizationName_default      = Cisco
localityName_default            = San Jose
stateOrProvinceName_default     = CA
countryName_default             = US
emailAddress_default            = webmaster@cisco.com
 
 
[ v3_ca ]
basicConstraints        = CA:TRUE
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always
 
 
 
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 
 
# Some CAs do not yet support subjectAltName in CSRs.
# Instead the additional names are form entries on web
# pages where one requests the certificate...
subjectAltName          = @alt_names
 
 
[alt_names]
IP.1   = 1.1.1.1
IP.2   = 2.2.2.2
IP.3   = 3.3.3.3
IP.4   = 4.4.4.4
 
 
[ server ]
# Make a cert with nsCertType set to "server"
basicConstraints=CA:FALSE
nsCertType                      = server
nsComment                       = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
 
 
[ client ]
# Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType                      = client
nsComment                       = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
Step 4

Once the directory structure is created and the configuration file (ca.cnf) is saved on your disk, create the TLS certificate file.

Generate the TLS private key and Certification Authority (CA) files by entering the openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/ca.pem -outform PEM -keyout mypersonalca/private/ca.key command. This step generates the TLS private key in PEM format with a key length of 2048 bits and the CA file.

Generate the certificates (server.key and server.crt ) file by entering: 

openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key -config ca.conf
Step 5

Copy server.key and server.crt into respective devices and install by using the following commands:

configure terminal to enter the configure terminal mode.

DEVICE# copy scp://<Username>@<Server_IP/home/TLS/server.crt bootflash: vrf management where bootflash:/// is the file location of server.key .

DEVICE# copy scp://<Username>@<Server_IP/home/TLS/server.key bootflash: vrf management where bootflash:/// is the file location of server.crt .

nxapi certificate httpskey keyfile bootflash:///server.key where bootflash:/// is the file location of server.key .

nxapi certificate httpscrt certfile bootflash:///server.crt where bootflash:/// is the file location of server.crt .

nxapi certificate enable

Step 6

Create the TLS KeyStore file.

Note 

The TLS KeyStore file should be placed in the configuration directory of Cisco Nexus Data Broker.

Copy server.key to xnc-privatekey.pem . This command copies the server.key file that was generated in the previous step. For example, use the command cp server.key xnc-privatekey.pem .

Copy server.crt to xnc-cert.pem . This command makes a copy of the server.crt file that was generated in previous step. For example, use the command cp server.crt xnc-cert.pem .

Create the xnc.pem file, that contains the private key and certificate, by entering the cat xnc-privatekey.pem xnc-cert.pem > xnc.pem command.

Convert the PEM file xnc.pem file to the file xnc.p12 file by entering the openssl pkcs12 -export -out xnc.p12 -in xnc.pem command. Enter a password at the prompt. This is the Export password. The password must contain at least 6 characters, for example, cisco123. You must use the same password in all the steps. The xnc.pem file is converted to a password-protected .p12 file.

Convert the xnc.p12 to a Java KeyStore (tlsKeyStore) file by entering the keytool -importkeystore -srckeystore xnc.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks command. This command converts the xnc.p12 file to a password-protected tlsKeyStore file. Enter a password at the prompt. Use the same password that you entered in previous step.

Step 7

Create the TLS TrustStore file.

The TLS TrustStore file should be placed in the application configuration directory.

Copy the mypersonalca/certs/ca.pem file to sw-cacert.pem .

Convert the sw-cacert.pem file to a Java TrustStore (tlsTrustStore) file by entering the keytool -import -alias swca1 -file sw-cacert.pem -keystore tlsTrustStore command.

Enter a password at the prompt. The sw-cacert.pem file is converted into a password-protected Java TrustStore (tlsTrustStore) file. The password must be at least six characters long, for example, cisco123

Step 8

Start application with TLS.

Complete these steps to start NDB application with TLS:

  1. Copy the tlsKeystore and tlsTruststore files to the configuration folder under NDB.

  2. Start Cisco Nexus Data Broker by entering the ./runxnc.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore command.

  3. Cisco Nexus Data Broker starts with TLS enabled.

Step 9

Provide the TLS KeyStore and TrustStore Passwords.

The TLS KeyStore and TrustStore passwords are synced to Cisco Nexus Data Broker so that it can read the password-protected TLS KeyStore and TrustStore files. Complete these steps to configure TLS KeyStore and TrustStore Passwords:

  1. Log in to Cisco NDB command interface.

  2. Navigate to the xnc/bin directory.

  3. Enter the TLS KeyStore and TLS TrustStore passwords using the ./xnc config-keystore-passwords [--user {user} --password {password} --url {url} --verbose --prompt --keystore-password {keystore_password} --truststore-password {truststore_password}] command.

    • user—The user name

    • password—The password for the user.

    • url—The web URL of the application.

    • keystore_password—The TLS KeyStore password.

    • truststore_password—The TLS TrustStore password. 

    ./xnc config-keystore-passwords --user admin --password admin --url https://Nexus_Data_Broker_IP:8443 --verbose --prompt --keystore-password cis123 --truststore-password cis123
Step 10

Add the switch into the controller using port number 443.

Note 

Switch cannot be added into the controller with port 80 after enabling TLS.

Step 11

Verify that the TLS communication is enabled on the switch using the show nxapi command. 

N9K# sh nxapi
nxapi enabled
HTTP Listen on port 80
HTTPS Listen on port 443
N9K#

You can also verify the TLS communication status by logging in to Nexus Device Sandbox UI using HTTPS and verify the certificates details and dates.

Generating TLS Self-Signed Certification Between NDB Server and NDB Switch for NXAPI

Complete the following steps to generate TLS self-signed certification between NDB Server and NDB Switch for NXAPI:

Procedure

Step 1

Create a TLS directory using the mkdir directory_name and navigate to the new directory.

Example:


[ndb]# mkdir -p TLS
[ndb]# cd TLS
Step 2

Create 3 directories under mypersonalca folder for CA system.

Example:


[ndb]# mkdir -p mypersonalca/certs
[ndb]# mkdir -p mypersonalca/private
[ndb]# mkdir -p mypersonalca/crl
Step 3

Initialize the serial file using the echo command. The serial file and the index.txt file are used by the CA to maintain its database of the certificate files.

Example:


[ndb]# echo "01" > mypersonalca/serial
Step 4

Initialize the index file using the touch command.

Example:


[ndb]# touch mypersonalca/index.txt
Step 5

Create a CA configuration file and configure the alt_names section with relevant IP Addresses.

Example:

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = .
serial = $dir/serial
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certs = $dir/certs
certificate = $certs/cacert.pem
private_key = $dir/private/cakey.pem
default_days = 365
default_md = sha1
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match
copy_extensions = copy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[req ]
default_bits = 2048 # Size of keys
default_keyfile = example.key # name of generated keys
default_md = sha1 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
req_extensions = v3_req
x509_extensions = v3_req
[ req_distinguished_name ]
# Variable name Prompt string
#---------------------- ----------------------------------
0.organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name (city, district)
stateOrProvinceName = State or Province Name (full name)
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64
# Default values for the above, for consistency and less typing.
# Variable name Value
#------------------------------ ------------------------------
commonName_default = www.cisco.com
0.organizationName_default = Cisco
localityName_default = San Jose
stateOrProvinceName_default = CA
countryName_default = US
emailAddress_default = webmaster@cisco.com
[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Some CAs do not yet support subjectAltName in CSRs.
# Instead the additional names are form entries on web
# pages where one requests the certificate...
subjectAltName = @alt_names
[alt_names]
IP.1 = 1.1.1.1
IP.2 = 2.2.2.2
IP.3 = 3.3.3.3
IP.4 = 10.16.206.104
[ server ]
# Make a cert with nsCertType set to "server"
basicConstraints=CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
[ client ]
# Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType = client
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
Step 6

Generate the TLS private key and Certification Authority (CA) files using the openssl req command. The TLS private key is created in PEM format with a key length of 2048 bits and the CA file.

Example:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/ca.pem -outform PEM -keyout mypersonalca/private/ca.key
Generating a 2048 bit RSA private key
..............................................................................................................................................+++
.....................................+++
writing new private key to 'mypersonalca/private/ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:CA
Locality Name (eg, city) [Newbury]:SJ
Organization Name (eg, company) [My Company Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu
Common Name (eg, your name or your server's hostname) []:N9K-104.cisco.com
Email Address []:xyz@abc.com
Step 7

Generate the certificate files, server.key and server.crt, using the openssl req command.

Example:

openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key -config ca.conf
Generating a 2048 bit RSA private key
.....+++
........................................+++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Organization Name (company) [Cisco]:cisco
Organizational Unit Name (department, division) []:insbu
Email Address [webmaster@cisco.com]:kemanoha@cisco.com
Locality Name (city, district) [San Jose]:SJ
State or Province Name (full name) [CA]:CA
Country Name (2 letter code) [US]:US
Common Name (hostname, IP, or your name) [www.cisco.com]:N9K-104.cisco.com
Step 8

Copy server.key and server.crt to the respective devices and install the certificate files using the nxapi certificate httpskey keyfile command.

Example:

configure terminal to enter the configure terminal mode.
DEVICE# copy scp://<Username>@<Server_IP/home/TLS/server.crt bootflash: vrf management where bootflash:/// is the file location of server.key.
DEVICE# copy scp://<Username>@<Server_IP/home/TLS/server.key bootflash: vrf management where bootflash:/// is the file location of server.crt.
nxapi certificate httpskey keyfile bootflash:///server.key where bootflash:/// is the file location of server.key.
nxapi certificate httpscrt certfile bootflash:///server.crt where bootflash:/// is the file location of server.crt.
nxapi certificate enable
Step 9

Create the TLS KeyStore file. Copy the TLS Keystore in the configuration directory of Cisco Nexus Data Broker.

Example:

Example:

# cp server.key xnc-privatekey.pem
//Copies server.key to xnc-privatekey.pem
# cp server.crt xnc-cert.pem
//Copies server.crt to xnc-cert.pem
# cat xnc-privatekey.pem xnc-cert.pem > xnc.pem
//Creates the xnc.pem file, that contains the private key and certificate
# openssl pkcs12 -export -out xnc.p12 -in xnc.pem
//Converts the PEM file xnc.pem file to the file xnc.p12 file. Enter the export 
//passowrd at the prompt. Use the same password in all the steps. The xnc.pem file 
//is converted to a password-protected .p12 file.
# keytool -importkeystore -srckeystore xnc.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
//Converts the xnc.p12 to a password protected Java KeyStore (tlsKeyStore) file
# cp server.crt xnc-cert.pem
Enter destination keystore password:
Re-enter new password:
Enter source keystore password:
Entry for alias 1 successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
Step 10

Create the TLS TrustStore file. Copy the TLS Keystore in the application configuration directory of Cisco Nexus Data Broker.

Example:

# cp mypersonalca/certs/ca.pem sw-cacert.pem
//Copies the mypersonalca/certs/ca.pem file to sw-cacert.pem
# keytool -import -alias swca1 -file sw-cacert.pem -keystore tlsTrustStore
//Converts the sw-cacert.pem file to a password protected Java TrustStore (tlsTrustStore) file
Enter keystore password:
Re-enter new password:
Owner: EMAILADDRESS=kemanoha@cisco.com, CN=N9K-104.cisco.com, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Issuer: EMAILADDRESS=kemanoha@cisco.com, CN=N9K-104.cisco.com, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Serial number: 9f383a65a18c77e8
Valid from: Sun May 13 18:25:12 PDT 2018 until: Wed May 10 18:25:12 PDT 2028
Certificate fingerprints:
MD5: BE:72:CD:62:3F:1F:DB:A3:E4:8F:E5:BE:7F:3A:3A:D3
SHA1: DA:A1:32:89:3C:C7:0E:A5:08:B3:D9:6C:BC:71:7B:C0:64:3B:CB:16
SHA256: 6D:DE:03:D1:A7:1C:16:CE:B2:72:46:90:6D:9B:7D:46:86:DC:5F:72:71:1B:3F:33:0B:99:9F:51:AD:B0:EC:DB
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: FE 5A C8 68 CE 8D D7 98 27 E8 54 88 87 89 63 F4 .Z.h....'.T...c.
0010: 1B 28 77 14 .(w.
]
[EMAILADDRESS=kemanoha@cisco.com, CN=N9K-104.cisco.com, OU=insbu, O=cisco, L=SJ, ST=CA, C=US]
SerialNumber: [ 9f383a65 a18c77e8]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: FE 5A C8 68 CE 8D D7 98 27 E8 54 88 87 89 63 F4 .Z.h....'.T...c.
0010: 1B 28 77 14 .(w.
]
]
Trust this certificate [no]: yes
Certificate was added to keystore
Step 11

Restart NDB application with TLS

Example:

# cp mypersonalca/certs/ca.pem sw-cacert.pem
//Copies the tlsKeystore and tlsTruststore files to the configuration folder under NDB.
# ./runxnc.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
//Starts the NSB application
Step 12

Enter the TLS KeyStore and TrustStore passwords.

Step 13

Configure TLS KeyStore and TrustStore Passwords

  1. Log in to Cisco NDB command interface.

  2. Navigate to the xnc/bin directory.

  3. Configure the TLS KeyStore and TLS TrustStore passwords using the ../xnc config-keystore-passwords [--user {user} --password {password} --url {url} --verbose --prompt --keystore-password {keystore_password} --truststore-password {truststore_password}] command.

    Example:

    . /xnc config-keystore-passwords --user admin --password admin --url https://Nexus_Data_Broker_IP:8443 --verbose --prompt --keystore-password pwd123 --truststore-password pwd123
Step 14

Add the switch into the controller using port number 443.

Note 

You cannot add a switch into the controller with port 80 after enabling TLS.
Step 15

Verify that the TLS communication is enabled on the switch using the show nxapi command.

Example:

N9K# sh nxapi 
nxapi enabled 
HTTP Listen on port 80 
HTTPS Listen on port 443 
N9K#
Note 

You can also verify the TLS communication status by logging in to Nexus Device Sandbox UI using HTTPS and verify the certificates details and dates.

Generating TLS Self-Signed Certification Between NDB Server and NDB Switch for OpenFlow

Complete the following steps to generate TLS self-signed certification between NDB Server and NDB Switch for OpenFlow:

Procedure

Step 1

Create a TLS directory using the mkdir directory_name and navigate to the new directory.

Example:


[]# mkdir -p TLS
[]# cd TLS
Step 2

Create 3 directories under mypersonalca folder for CA system.

Example:


[]# mkdir -p mypersonalca/certs
[]# mkdir -p mypersonalca/private
[]# mkdir -p mypersonalca/crl
Step 3

Initialize the serial file using the echo command. The serial file and the index.txt file are used by the CA to maintain its database of the certificate files.

Example:


[]# echo "01" > mypersonalca/serial
Step 4

Initialize the index file using the touch command.

Example:


[]# touch mypersonalca/index.txt
Step 5

Create a CA configuration file and configure the alt_names section with relevant IP Addresses.

Example:

[ ca ]
default_ca = mypersonalca
[ mypersonalca ]
#
# WARNING: if you change that, change the default_keyfile in the [req] section below too
# Where everything is kept
dir = ./mypersonalca
# Where the issued certs are kept
certs = $dir/certs
# Where the issued crl are kept
crl_dir = $dir/crl
# database index file
database = $dir/index.txt
# default place for new certs
new_certs_dir = $dir/certs
#
# The CA certificate
certificate = $dir/certs/ca.pem
# The current serial number
serial = $dir/serial
# The current CRL
crl = $dir/crl/crl.pem
# WARNING: if you change that, change the default_keyfile in the [req] section below too
# The private key
private_key = $dir/private/ca.key
# private random number file
RANDFILE = $dir/private/.rand
# The extentions to add to the cert
x509_extensions = usr_cert
# how long to certify for
default_days = 365
# how long before next CRL
default_crl_days= 30
# which md to use; people in comments indicated to use sha1 here
default_md = sha1
# keep passed DN ordering
preserve = no
# Section names
policy = mypolicy
x509_extensions = certificate_extensions
[ mypolicy ]
# Use the supplied information
commonName = supplied
stateOrProvinceName = optional
countryName = optional
emailAddress = optional
organizationName = optional
organizationalUnitName = optional
[ certificate_extensions ]
# The signed certificate cannot be used as CA
basicConstraints = CA:false
[ req ]
# same as private_key
default_keyfile = ./mypersonalca/private/ca.key
# Which hash to use
default_md = sha1
# No prompts
prompt = no
# This is for CA
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
string_mask = utf8only
basicConstraints = CA:true
distinguished_name = root_ca_distinguished_name
x509_extensions = root_ca_extensions
[ root_ca_distinguished_name ]
commonName = Controller
stateOrProvinceName = Mass
countryName = US
emailAddress = root_ca_userid@cisco.com
organizationName = Cisco
[ root_ca_extensions ]
basicConstraints = CA:true
Step 6

Generate the TLS private key, certificate, and Certification Authority (CA) files using the openssl req command. The TLS private key is created in PEM format with a key length of 2048 bits and the CA file.

Example:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/ca.pem -outform PEM -keyout mypersonalca/private/ca.key
Generating a 2048 bit RSA private key
.............+++
...............................+++
writing new private key to 'mypersonalca/private/ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Mass
Locality Name (eg, city) []:San
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Cisco
Organizational Unit Name (eg, section) []:NDB
Common Name (e.g. server FQDN or YOUR name) []:Controller
Email Address []:masavanu@cisco.com
Note 

This step generates the TLS private key in PEM format with a key length of 2048 bits, and the CA file.
Step 7

Generate the certificate key and certificate request files, using the openssl req command.

Example:

openssl req -newkey rsa:2048 -keyout cert.key -keyform PEM -out cert.req -outform PEMGenerating a 2048 bit RSA private key
Generating a 2048 bit RSA private key
.........................................+++
........+++
writing new private key to 'cert.key'
Enter PEM pass phrase:(Enter pwd123 here)
Verifying - Enter PEM pass phrase:(Enter pwd123 here)
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Mass
Locality Name (eg, city) []:San
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Cisco
Organizational Unit Name (eg, section) []:NDB
Common Name (e.g. server FQDN or YOUR name) []:Controller
Email Address []:masavanu@cisco.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:pwd123
An optional company name []:
Note 

This step generates the controller key (cert.key) and certificate request (cert.req) files in PEM format.
Step 8

Generate the certificate file, using the openssl ca command.

Example:

openssl ca -batch -notext -in cert.req -out cert.pem -config ca.cnf
Using configuration from ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :ASN.1 12:'Mass'
localityName :ASN.1 12:'San'
organizationName :ASN.1 12:'Cisco'
organizationalUnitName:ASN.1 12:'NDB'
commonName :ASN.1 12:'Controller'
emailAddress :IA5STRING:'masavanu@cisco.com'
Certificate is to be certified until May 17 02:59:40 2017 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
Note 

This step generates the certificate (cert.pem) file in PEM format using the certificate request (cert.req) and the certificate configuration (ca.cnf) files.

Step 9

Configure the Cryptographic Keys on the Switch.

Example:

switch(config)# ip domain-name domain-name
//Configures the domain name for the switch
switch(config)# crypto key generate rsa label myKey2 exportable modulus 2048
//Generates the cryptographic key.
switch(config)# crypto ca trustpoint myCA
//Enters the trustpoint configuration mode and installs the trustpoint file on the switch
switch(config-trustpoint)# rsakeypair myKey2
//Installs the key files on the switch
switch(config-trustpoint)# exit
//Exits trustpoint configuration mode
switch# show crypto ca trustpoints
//(Optional) Verifies creation of the trustpoint files.
switch# show crypto key mypubkey rsa
//(Optional) Verifies creation of the key files.
cat mypersonalca/certs/ca.pem
//Displays the certificate file on the machine hosting the generated TLS certificates
switch(config)# crypto ca authenticate myCA
-----BEGIN CERTIFICATE----------
-----END CERTIFICATE-----
END OF INPUT:
Fingerprint(s): SHA1 Fingerprint=56:0F:56:85:6A:07:A1:44:6C:F4:4C:45:CF:CC:BA:47:22:17:1D:93
Do you accept this certificate [yes/no]:yes

switch(config)# crypto ca enroll myCA
//Generates the certificate request on the switch

Create the certificate request ..
Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:pwd123
The subject name in the certificate will be the name of the switch.
Include the switch serial number in the subject name [yes/no]:no
Include an IP address in the subject name [yes/no]:no
Include the Alternate Subject Name  [yes/no]:no
The certificate request will be displayed...
-----BEGIN CERTIFICATE REQUEST-----
……………………
-----END CERTIFICATE REQUEST-----
openssl ca -in n3k-cert.req -out newcert.pem -config ./ca.cnf
//Copies the certificate request from the switch to the file n3k-cert.req on your Linux machine, and then uses it to generate the switch certificate.
Using configuration from ./ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :PRINTABLE:'ndb-3172-4.cisco.com'
Certificate is to be certified until May 17 04:27:57 2017 GMT (365 days)
Sign the certificate [y/n]:y
out of 1 certificate requests certified, commit [y/n]y
Write out database with 1 new entries
Data Base Updated

cat newcert.pem
//Copies the certificate (newcert.pem) to the switch

switch(config)# crypto ca import myCA certificate
switch(config)# crypto ca import myCA certificate
input (cut & paste) certificate in PEM format:

switch# show crypto ca certificates
//Displays the certificates on the switch
Step 10

Enable the TLS OpenFlow Switches

Example:

switch(config)# openflow
//Enters OpenFlow agent configuration mode on the switch.
switch(config-ofa)# switch 1
//Enters OpenFlow agent configuration mode for switch 1.
switch(config-ofa)# tls trust-point local myCA remote myCA
//Enables TLS certificate authority on the switch.
switch(config-ofa-switch)# pipeline{201/203}
//Configures the pipeline
switch(config-ofa-switch)#controller ipv4 {A.B.C.D} port 6653 vrf management security tls
//Enables TLS for OpenFlow switches
Step 11

Create the TLS KeyStore File

Example:

cp cert.key xnc-privatekey.pem
//Copy cert.key to xnc-privatekey.pem
cp cert.pem xnc-cert.pem
//Copy cert.pem to xnc-cert.pem under TLS folder
cat xnc-privatekey.pem xnc-cert.pem > xnc.pem
Creates the xnc.pem file, which contains the private key and certificate.

openssl pkcs12 -export -out xnc.p12 -in xnc.pem
//Convert the PEM file xnc.pem file to the file xnc.p12
Enter a password at the prompt
The xnc.pem file is converted to a password-protected .p12 file.
openssl pkcs12 -export -out xnc.p12 -in xnc.pem
Enter pass phrase for xnc.pem:(enter pass phrase as pwd123)
Enter Export Password:(Enter Export password as pwd123)
Verifying - Enter Export Password:(Enter as pwd123)
Step 12

Convert the xnc.p12 file to password protected TLS KeyStore

Example:

keytool -importkeystore -srckeystore xnc.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
Enter destination keystore password: (Enter pwd123)
Re-enter new password: (Enter pwd123)
Enter source keystore password: (Enter pwd123)
Entry for alias 1 successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
Step 13

Enter the TLS KeyStore password.

Step 14

Create the TLS TrustStore File.

Example:

cp mypersonalca/certs/ca.pem sw-cacert.pem
//Copies the mypersonalca/certs/ca.pem file to sw-cacert.pem
keytool -import -alias swca1 -file sw-cacert.pem -keystore tlsTrustStore
Enter keystore password: (Enter pwd123)
Re-enter new password: (Enter pwd123)
Owner: EMAILADDRESS=masavanu@cisco.com, CN=Controller, OU=NDB, O=Cisco, L=San, ST=Mass, C=US
Issuer: EMAILADDRESS=masavanu@cisco.com, CN=Controller, OU=NDB, O=Cisco, L=San, ST=Mass, C=US
Serial number: d764c5b1e5e6b531
Valid from: Mon May 16 22:49:13 EDT 2016 until: Thu May 14 22:49:13 EDT 2026
Certificate fingerprints:
MD5: BD:C8:21:13:D0:7F:ED:A4:B4:FA:97:9A:D0:EA:12:78
SHA1: 56:0F:56:85:6A:07:A1:44:6C:F4:4C:45:CF:CC:BA:47:22:17:1D:93
SHA256: 09:32:74:12:BF:56:04:07:42:8C:D8:1B:78:AD:7A:40:0D:51:AA:56:91:B1:1A:18:90:6A:A5:A0:44:04:6A:EC
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 78 C5 2B 09 7F AF EC 86 FE 50 EA 6C 8A 56 B3 BE x.+......P.l.V..
0010: BE F2 97 98 ....
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 78 C5 2B 09 7F AF EC 86 FE 50 EA 6C 8A 56 B3 BE x.+......P.l.V..
0010: BE F2 97 98 ....
]
]
Trust this certificate [no]: yes
Certificate was added to keystore
Note 

The sw-cacert.pem file is converted into a password-protected Java TrustStore (tlsTrustStore) file.

Starting the NDB Application with TLS Enabled

Complete the following steps to start NDB application with TLS enabled.

Before you begin

Copy TLS Truststore and TLS Keystore files created under TLS folder to the configuration directory of Cisco Nexus Data Broker.

Procedure

Step 1

Start the NDB application using the runxnc.sh script.

Example:

./runxnc.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore

Example:

To start NDB with default username (admin) and a non-default password (for example, pwd123):

./runxnc.sh -osgiPasswordSync -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
If XNC password is changed, OSGi webconsole password needs to be changed, 
to set non-default OSGi webconsole password Enter XNC Admin Password [default] :( Type the non-default password which was set.

Example:

To start NDB with default username (admin) and password (admin):

./runxnc.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
Step 2

Configure the TLS KeyStore and TrustStore passwords in Cisco NDB. You need to configure TLS KeyStore and TrustStore Passwords to enable NDB to read the password-protected TLS KeyStore and TrustStore files.

Example:


xnc/bin directory# ./xnc config-keystore-passwords --user admin --password admin --url https://NDB_URL:8443
--verbose --prompt --keystore-password pwd123 --truststore-password pwd123

If the TLS KeyStore and TrustStore passwords configuration fails with Failed to connect to the controller, you need to change the protocol to HTTP. 

./xnc config-keystore-passwords --user admin --password admin --url https://localhost:8443 --verbose --prompt --keystore-password pwd123 --truststore-password pwd123 
[Info] Sending request: https://10.16.206.189:8443/controller/osgi/system/console/vmstat 
---- REQUEST HEADERS ---- 
GET https://10.16.206.189:8443/controller/osgi/system/console/vmstat HTTP/1.1 
------------------------- 
[Error] Failed to connect to the controller at "https://10.16.206.189:8443". Controller may not be running. 
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: 
No subject alternative names present 
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) 
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) 
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) 
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509) 
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) 
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) 
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) 
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) 
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) 
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) 
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) 
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) 
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) 
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513) 
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) 
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) 
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338) 
at com.cisco.csdn.cli.online.HttpClient$HttpResponse.<init>(HttpClient.java:191) 
at com.cisco.csdn.cli.online.HttpClient.sendRequest(HttpClient.java:108) 
at com.cisco.csdn.cli.online.HttpClient.get(HttpClient.java:92) 
at com.cisco.csdn.cli.online.OnlineCommand.isRunning(OnlineCommand.java:88)
at com.cisco.csdn.cli.online.ConfigKeyStorePasswordCommand.processCommand(ConfigKeyStorePasswordCommand.java:46) 
at com.cisco.csdn.cli.Cli.processCommand(Cli.java:70) 
at com.cisco.csdn.cli.Main.main(Main.java:33) 
Caused by: java.security.cert.CertificateException: No subject alternative names present 
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:144) 
at sun.security.util.HostnameChecker.match(HostnameChecker.java:93) 
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) 
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436) 
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:200) 
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) 
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491) 
... 20 more

//Change the protocol to HTTP.
./xnc config-keystore-passwords --user admin --password admin --url http://localhost:8080
--verbose --prompt --keystore-password pwd123 --truststore-password pwd123

Generating the Java tlsKeyStore and tlsTrustStore for NDB Controller

Complete the following steps to generate the Java tlsKeyStore and tlsTrustStore files for NDB Controller:

Procedure

Step 1

Create a TLS directory using the mkdir directory_name and navigate to the new directory.

Example:


[]# mkdir -p TLS
[]# cd TLS
Step 2

Create 3 directories under mypersonalca folder for CA system.

Example:


[]# mkdir -p mypersonalca/certs
[]# mkdir -p mypersonalca/private
[]# mkdir -p mypersonalca/crl
Step 3

Initialize the serial file using the echo command. The serial file and the index.txt file are used by the CA to maintain its database of the certificate files.

Example:


[]# echo "01" > mypersonalca/serial
Step 4

Initialize the index file using the touch command.

Example:


[]# touch mypersonalca/index.txt
Step 5

Generate the TLS private key and Certification Authority (CA) files for each switch connected to NDB using the openssl req command. The TLS private key is created in PEM format with a key length of 2048 bits and the CA file.

Example:

docker@docker-virtual-machine:~/TLS$ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -out mypersonalca/certs/sw1-ca.pem -outform PEM -keyout mypersonalca/private/sw1-ca.key

Generating a 2048 bit RSA private key
...+++
............................................+++
writing new private key to 'mypersonalca/private/sw1-ca.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value, If you enter '.', the field will be left blank.
----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []:SJ Organization Name (eg, company) [Internet Widgits Pty Ltd]:cisco
Organizational Unit Name (eg, section) []:insbu Common Name (e.g. server FQDN or YOUR name) []:N9K-117.cisco.com Email Address []:myname@cisco.com
Note 

Save the sw1-ca.pem file in mypersonalca/certs directory and sw1-ca.key file in the mypersonalca/private directory.

Step 6

Copy the cert.key and server.cer to each switch.

Example:

cp cert.key sw1-xnc-privatekey.pem
cp server.cer sw1-xnc-cert.pem
Step 7

Create the sw1-xnc.pem file, which contains the private key and certificate using the cat command.

Example:

cat sw1-xnc-privatekey.pem sw1-xnc-cert.pem > sw1-xnc.pem
Step 8

Convert the PEM file to PKSC12 file format, using the openssl command. For example, sw1-xnc.pem file to sw1-xnc.p12 file.

Example:

docker@docker-virtual-machine:~/TLS$ openssl pkcs12 -export - out sw1-xnc.p12 -in sw1-xnc.pem
Enter Export Password:pwd123
Verifying - Enter Export Password:pwd123
Enter a password at the prompt. Use the same password that you entered in previous Step(pwd123)
Step 9

Convert the sw1-xnc.p12 to a password protected Java KeyStore (tlsKeyStore) file using the keytool command.

Example:

docker@docker-virtual-machine:~/TLS$ keytool -importkeystore -srckeystore sw1-xnc.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
Enter destination keystore password:pwd123
Re-enter new password: pwd123
Enter source keystore password: pwd123
Entry for alias 1 successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled
Note 

By default, an allias named “1” is stored in tlsKeyStore for the first switch. When the second switch is added, the utility lets you to rename the first switch alias and also provides a provision to give alias name for the new switck.

Note 

If the NDB controller is managing multiple switches, repeat the above step for all the switches.
Step 10

List and verift the contents in the Java tlsKeyStore file after all the certificates are added to the keystore using the keytool command.

Example:

keytool -list -v -keystore tlsKeyStore | more
Step 11

Create the TLS TrustStore File.

Example:

docker@docker-virtual-machine:~/TLS$ keytool -import -alias sw1 -file mypersonalca/certs/sw1-ca.pem -keystore tlsTrustStore
Enter keystore password: pwd123
Re-enter new password: pwd123
Owner: EMAILADDRESS=myname@cisco.com, CN=localhost, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Issuer: EMAILADDRESS=myname@cisco.com, CN=localhost, OU=insbu, O=cisco, L=SJ, ST=CA, C=US
Serial number: c557f668a0dd2ca5
Valid from: Thu Jun 15 05:43:48 IST 2017 until: Sun Jun 13
05:43:48 IST 2027
Certificate fingerprints:
MD5: C2:7B:9E:26:31:7A:74:25:55:DF:A7:91:C9:5D:20:A3
SHA1:
3C:DF:66:96:72:12:CE:81:DB:AB:58:30:60:E7:CC:04:4D:DF:6D:B2
SHA256: DD:FB:3D:71:B4:B8:9E:CE:97:A3:E4:2D:D3:B6:90:CD:76:A8:5F:84:77
:78:BE:49:6C:04:01:84:62:2C:2F:EB
Signature algorithm name: SHA256withRSA Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [ KeyIdentifier [
0000: 0D B3 CF 81 66 4A 33 4E EF 86 7E 26 C3 50 9B 73
....fJ3N...&.P.s
0010: 38 EF DF 40 8..@
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[ CA:true PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [ KeyIdentifier [
0000: 0D B3 CF 81 66 4A 33 4E EF 86 7E 26 C3 50 9B 73
....fJ3N...&.P.s
0010: 38 EF DF 40 8..@
]
]
Trust this certificate [no]: yes
Certificate was added to keystore
Note 

If NDB controller manages multiple switches, add all switch keys into the same TrustStore. Use keytool -list -v -keystore tlsTrustStore | more command to see the keys for multiple switches in the same tlsTrustStore.

Step 12

Start the NDB application with TLS.

Example:

./runxnc.sh –stop
cp tlsKeystore xnc/configuration
cp tlsTruststore xnc/configuration
./runxnc.sh -tls -tlskeystore ./configuration/tlsKeyStore -tlstruststore ./configuration/tlsTrustStore
Step 13

Configure the TLS KeyStore and TrustStore passwords in Cisco NDB. You need to configure TLS KeyStore and TrustStore Passwords to enable NDB to read the password-protected TLS KeyStore and TrustStore files.

Example:


xnc/bin directory# ./xnc config-keystore-passwords --user admin --password admin --url https://NDB_URL:8443
--verbose --prompt --keystore-password pwd123 --truststore-password pwd123
Table 1. Troubleshooting TLS Implementation

Error Log

Cause

Solution

2017-06-23 18:41:52.787 IST [http-bio-8443-exec-7] DEBUG com.cisco.csdn.protocol_plugin.nxapi.service.internal.RestServices - REST method: POST url: https://10.16.206.117:443/ins caught exception: Certificate for <10.16.206.117> doesn't match common name of the certificate subject: N9k-117.cisco.com

2017-06-23 18:41:52.787 IST [http-bio-8443-exec-7] ERROR com.cisco.csdn.protocol_plugin.nxapi.core.internal.ElementHandler - Failed to connect to 10.16.206.117, Error: javax.net.ssl.SSLException: Certificate for <10.16.206.117> doesn't match common name of the

certificate subject: N9k-117.cisco.com

Occurs when the common name used in the certificate does not match names the switch.

  1. Add switch FQDN in /etc/hosts on the serever where NDB is running to resolve the DNS (if you have configured a DNS, this solution may not help.)

  2. Add the switch using FQDN in NDB device connection – for example, use N9K-117.cisco.com instead of IP address.

  3. Ensure that IP domain and hostname are correctly configured in the switch.

  4. Switch FQDN is resolved through DNS

Generating TLS Self-Signed Certification Between WebUI Browser and NDB Server

By default Cisco NDB is shipped with default certificate which is issued to Cisco XNC and issued by Cisco XNC with default validity. You can use the generateWebUIcertificate.sh script under configuration folder to create self-signed certificates that are valid for 6 months. You can also configure the validity of certificate. Complete the following steps to generate TLS self-signed certification between WebUI Browser and NDB Server:

Procedure

Step 1

Generate the TLS self-signed certificate using the generateWebUIcertificate.sh script.

Example:


cisco@cisco:~/user/NDB3.5_centra_cco/xnc/configuration$ ./generateWebUIcertificate.sh
 *********************************** 
Enter Fully qualified domain name: 
*********************************** 
10.16.206.117 (This can be FQDN of the NDB java application as well). 
*************************** 
Enter Organizational unit : 
*************************** 
INSBU 
******************** 
Enter Organization : 
******************** 
cisco 
**************** 
Enter Location : 
**************** 
SJ 
************* 
Enter State : 
************* 
CA 
*************** 
Enter Country : 
*************** 
USA 
*************** 
Enter keypass : 
*************** 
pwd123 
*****************
Enter storepass : 
****************** 
pwd123 
************************************** 
Enter the validity in number of days : 
************************************** 
365 
********************************************************************************************************************************* 
Below process will rename the existing key file to <old_keystore>, will generate a new key file. Do you want to continue (y/n)? 
********************************************************************************************************************************* 
y 
******************************* 
Self-Signed Certificate Created 
******************************* 
Alias name: cisco 
Creation date: Jan 3, 2018 
Entry type: PrivateKeyEntry 
Certificate chain length: 1 
Certificate[1]: 
Owner: CN=10.16.206.117, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA 
Issuer: CN=10.16.206.117, OU=INSBU, O=cisco, L=SJ, ST=CA, C=USA 
Serial number: 2e61c095 
Valid from: Wed Jan 03 07:05:39 EST 2018 until: Thu Jan 03 07:05:39 EST 2019 
Certificate fingerprints: 
MD5: 9F:9C:A2:2C:48:89:05:B9:54:DA:5E:84:57:E2:84:0B 
SHA1: 6D:A2:C4:11:0C:65:E5:C2:2A:33:BA:39:9E:52:2A:EF:76:33:C1:E6 
SHA256: 11:A6:B6:88:BA:91:81:41:7C:73:D3:5B:ED:AE:FD:96:B5:B7:F4:C6:16:67:CF:96:77:FD:67:74:BF:2B:1A:6B 
Signature algorithm name: SHA256withRSA 
Version: 3 
Extensions: 
#1: ObjectId: 2.5.29.14 Criticality=false 
SubjectKeyIdentifier 
[ KeyIdentifier [ 0000: 95 88 E6 C9 07 A7 1C 7C 9B 0F AC F6 76 16 5C 9D ............v.\. 0010: E5 AB 17 FF .... ] ]
******************************** 
Displayed the generated keystore 
******************************** 
**************************************************** 
Configured the keystore details on tomcat-server.xml 
**************************************************** 
********************************************************************************************** 
The newly generated key will used on next NDB restart. Do you want to restart NDB now (y/n) ? 
********************************************************************************************** 
y 
Controller with PID: 11757 -- Stopped! 
Another instance of controller running, check with ./runxnc.sh -status 
************* 
NDB Restarted 
************* 
cisco@cisco:~/user/NDB3.5_centra_cco/xnc/configuration$ ps -ef | grep java 
cisco 19320 1 99 07:06 pts/6 00:00:08 jre1.8.0_131/bin/java -server -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -XX:MaxMetaspaceSize=256m 
-Djava.io.tmpdir=/home/cisco/Mallik/NDB3.5_centra_cco/xnc/work/tmp 
-Dosgi.install.area=/home/cisco/Mallik/NDB3.5_centra_cco/xnc 
-Dosgi.configuration.area=/home/cisco/Mallik/NDB3.5_centra_cco/xnc/configuration 
-Dosgi.frameworkClassPath=file:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.osgi-3.8.1.v20120830-144521.jar,
file:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.virgo.kernel.equinox.extensions-3.6.0.RELEASE.jar,
file:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.equinox.launcher-1.3.0.v20120522-1813.jar 
-Dosgi.framework=file:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.osgi-3.8.1.v20120830-144521.jar 
-Dosgi.console.ssh=2400 -Djava.awt.headless=true -Dinteractive=0 
-classpath /home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.osgi-3.8.1.v20120830-144521.
jar:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.virgo.kernel.equinox.extensions-3.6.0.RELEASE.
jar:/home/cisco/Mallik/NDB3.5_centra_cco/xnc/lib/org.eclipse.equinox.launcher-1.3.0.v20120522-1813.
jar org.eclipse.equinox.launcher.Main -consoleLog cisco 23419 18805 0 07:06 pts/6 00:00:00 grep --color=auto java 
cisco@cisco:~/Mallik/NDB3.5_centra_cco/xnc/configuration$
Note 

Use keytool -list -v -keystore keystore_Name command to decode the certificate.

Note 

The generateWebUIcertificate.sh script reloads the NDB application to ensure that the browser starts using this certificate when we access NDB java application from the browser.

Step 2

Add this certificate to Trusted Root certificate store on the browser. See help for respective Web browsers about how to add the certificate to the Trusted Root certificate store.

Converting JKS Format Key to PKCS12 Format

The self-signed certificates are generated in JKS format which is not compatible with the browsers. Hence, you need to convert these certificates into PKCS12 format before importing the certificate in the browser. Complete the following steps to convert JKS format certificate to PKCS12 format.


Note

Ensure that you keep a copy of the original certificates before proceeding with the conversion.

Procedure

Step 1

Convert JKS format certificate into PKCS12 format using the keytool command.

Example:


 keytool -importkeystore -srckeystore keystore -srcstorepass pwd123 -srckeypass pwd123 -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias cisco -deststorepass pwd123 -destkeypass pwd123
Note 

The inputs in the keytool command should match the inputs provided during UI certificate generation.

Note 

The resulting certificate (keystore.p12) created is in PKSC12 format.
Step 2

Upload the certificate into Trusted Root certificate store of Web browser. See help for respective Web browsers about how to add the certificate to the Trusted Root certificate store.

Generating TLS 3rd Party Certification Between WebUI Browser and NDB Server

Complete the following steps to generate TLS 3rd party certification between NDB Server and WebUI browser :

Procedure

Step 1

Generate Certificate Signing Request (CSR) using the openssl req command.

Example:


docker@docker-virtual-machine:~/Mallik/TLS_CA$  openssl req -newkey rsa:2048 -sha256 -keyout cert.key -keyform PEM -out cert.req -outform PEM
Generating a 2048 bit RSA private key
 ...............+++ 
....................+++ 
writingnew private key to 'cert.key' 
Enter PEM pass phrase: pwd123 
Verifying - Enter PEM pass phrase: pwd123 
----- 
You are about to be asked to enter information that will be incorporated into your certificate request. 
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank 
For some fields there will be a default value, If you enter '.', the field will be left blank.
 ----- 
Country Name (2 letter code) [GB]:US 
State or Province Name (full name) [Berkshire]:CA 
Locality Name (eg, city) [Newbury]:SJ 
Organization Name (eg, company) [My Company Ltd]:cisco 
Organizational Unit Name (eg, section) []:insbu 
Common Name (eg, your name or your server's hostname) []:N9K-117.cisco.com à this will be NDB application url) 
Email Address []:myname@cisco.com 
Please enter the following 'extra' attributes to be sent with your certificate request 
A challenge password []: pwd123 
An optional company name []:pwd123 
docker@docker-virtual-machine: # ls cert.key cert.req
Note 

You need to use the same information when exporting the CA provided certificate into browser. The CSR file, cert.req, is submitted to CA.

Step 2

To verify or view the CSR request, use the openssl req command.

Example:


[??]# openssl req -noout -text -in cert.req

Converting CA Provided Certificate into JKS Format

CA provides certificates in PEM format and extension of the certificate is .pem. You need to convert the PEM format certificate to PKCS12 format. Complete the following steps to convert PEM format certificate to PKCS12 format.


Note

Ensure that you keep a copy of the original certificates before proceeding with the conversion.

Procedure

Step 1

Convert PEM format certificate into PKCS12 format using the openssl pkcs12 command.

Example:


 openssl pkcs12 -export -out sw1-xnc.p12 -in sw1-xnc.pem
Note 

Use the export password.
Note 

You need to use the same information when exporting the CA provided certificate into browser. The CSR file, cert.req, is submitted to CA.

Step 2

Convert the sw1-xnc.p12 to a password-protected tlsKeyStore file, use the keytool command.

Example:


[??]# keytool -importkeystore -srckeystore sw1-xnc.p12 -srcstoretype pkcs12 -destkeystore tlsKeyStore -deststoretype jks
Note 

Use the keytool -list -v -keystore tlsKeyStore command to decode the keystore.

Step 3

Copy the converted certificate into NDB xnc/configuration directory and refer to this file in tomcat-server.xml file.
Step 4

Configure the tomcat server configuration flle (tomcat-server.xml) to the converted certificate.

Example:

keystoreFile="configuration/keystore"
keystorePass="ciscoxnc"
Step 5

Start the NDB application.
Step 6

Upload the CA certificate into Trusted Root certificate store of Web browser. See help for respective Web browsers about how to add the certificate to the Trusted Root certificate store.