Implementing Certification Authority Interoperability

Certification authority (CA) interoperability is provided in support of the IP Security (IPSec), Secure Socket Layer (SSL), and Secure Shell (SSH) protocols. This module describes how to implement CA interoperability.

CA interoperability permits Cisco ASR 9000 Series Router devices and CAs to communicate so that your device can obtain and use digital certificates from the CA. Although IPSec can be implemented in your network without the use of a CA, using a CA provides manageability and scalability for IPSec.


Note

IPSec is supported only for Open Shortest Path First version 3 (OSPFv3).

For a complete description of the public key infrastructure (PKI) commands used in this chapter, refer to the Public Key Infrastructure Commands module in System Security Command Reference for Cisco ASR 9000 Series Routers.

Feature History for Implementing Certification Authority Interoperability

Release

Modification

Release 3.7.2

This feature was introduced.

Release 7.0.1 Added topics on Integrating Cisco IOS XR and Crosswork Trust Insights.

Release 7.3.1

Added support for Ed25519 Public-Key Signature System.

Release 7.3.1

Added support for verifying authenticity of RPM packages using runtime and install time fingerprint.

Release 7.3.1

Added support to collect filesystem inventory.

Release 7.3.1

Added support for optimizations via IMA.

Prerequisites for Implementing Certification Authority

The following prerequisites are required to implement CA interoperability:

  • You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

  • You need to have a CA available to your network before you configure this interoperability feature. The CA must support Cisco Systems PKI protocol, the simple certificate enrollment protocol (SCEP) (formerly called certificate enrollment protocol [CEP]).

Restrictions for Implementing Certification Authority

  • Cisco IOS XR software doesn’t support CA server public keys greater than 2048 bits.

  • Starting with Cisco IOS XR software version 7.3.3, the server certificates (leaf certificates) in the router must have a Fully Qualified Domain Name (FQDN) in the Common Name (CN) field.

  • To add an IP address in the Subject Alternate Name (SAN) field of server certificates, add the extension type as IP address in the certificate. If the IP address extension type configuration isn’t available, use the crypto ca fqdn-check ip-address allow command for the router to validate the IP address in the SAN field successfully.

  • Starting Cisco IOS XR Software Release 7.4.1, we mandate the below X509 certificate Subject Alternate Name (SAN) fields and domain name server configuration to validate SAN. TLS connection cannot be established if there is no domain name-server is configured.

    Here are some key-points regarding SAN field:

    • SAN must be a fully-qualified domain name. For example, DNS:smartreceiver.cisco.com

    • SAN must be a critical extension in the absence of Common Name (CN).

    • If the SAN cannot be represented as a FQDN, then it must be configured with GeneralName field as IP Address but not as DNS. For example, IP address: 192.0.2.1

    To configure domain name-server use the domain name-server ip-address .

    To configure domain name-server with VRF, use the following commands:

    • domain vrf name-serverip-address

    • Use the crypto ca trustpoint-name vrf vrf-name command when you are using VRF.

    • Use the crypto ca trustpoint Trustpool vrf vrf-name command for smart-licensing.

    For Static Domain Name Configuration, use the domain ipv4 host host-name ip-address command. and for configuring static domain name using VRF, use the domain ipv4 vrf vrf-name host-name ip-address command.

  • Starting Cisco IOS XR Software Release 7.4.2, you can bypass FQDN and IP address check in SAN by configuring crypto ca fqdn-check ip-address allow.

Information About Implementing Certification Authority

To implement CA, you need to understand the following concepts:

Supported Standards for Certification Authority Interoperability

Cisco supports the following standards:

  • IPSec—IP Security Protocol. IPSec is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses Internet Key Exchange (IKE) to handle negotiation of protocols and algorithms based on local policy, and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, a pair of security gateways, or a security gateway and a host.

    Note
    IPSec is supported only for Open Shortest Path First version 3 (OSPFv3).

  • IKE—A hybrid protocol that implements Oakley and Skeme key exchanges inside the Internet Security Association Key Management Protocol (ISAKMP) framework. Although IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec security associations (SAs).

  • Public-Key Cryptography Standard #7 (PKCS #7)—A standard from RSA Data Security Inc. used to encrypt and sign certificate enrollment messages.

  • Public-Key Cryptography Standard #10 (PKCS #10)—A standard syntax from RSA Data Security Inc. for certificate requests.

  • RSA keys—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adelman. RSA keys come in pairs: one public key and one private key.

  • SSL—Secure Socket Layer protocol.

  • X.509v3 certificates—Certificate support that allows the IPSec-protected network to scale by providing the equivalent of a digital ID card to each device. When two devices want to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or specify a shared key at each peer). These certificates are obtained from a CA. X.509 as part of the X.500 standard of the ITU.

Certification Authorities

The following sections provide background information about CAs:

Purpose of CAs

CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.

CAs simplify the administration of IPSec network devices. You can use a CA with a network containing multiple IPSec-compliant devices, such as routers.

Digital signatures, enabled by public key cryptography, provide a means of digitally authenticating devices and individual users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other. In simple terms, a signature is formed when data is encrypted with a user’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. The fact that the message could be decrypted using the sender’s public key indicates that the holder of the private key, the sender, must have created the message. This process relies on the receiver’s having a copy of the sender’s public key and knowing with a high degree of certainty that it does belong to the sender and not to someone pretending to be the sender.

Digital certificates provide the link. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity’s public key. The certificate is itself signed by a CA, a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.

To validate the signature of the CA, the receiver must first know the CA’s public key. Normally, this process is handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default. IKE, an essential component of IPSec, can use digital signatures to authenticate peer devices for scalability before setting up SAs.

Without digital signatures, a user must manually exchange either public keys or secrets between each pair of devices that use IPSec to protect communication between them. Without certificates, every new device added to the network requires a configuration change on every other device with which it communicates securely. With digital certificates, each device is enrolled with a CA. When two devices want to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, a user simply enrolls that device with a CA, and none of the other devices needs modification. When the new device attempts an IPSec connection, certificates are automatically exchanged and the device can be authenticated.

IPSec Without CAs

Without a CA, if you want to enable IPSec services (such as encryption) between two Cisco routers, you must first ensure that each router has the key of the other router (such as an RSA public key or a shared key). This requirement means that you must manually perform one of the following operations:

  • At each router, enter the RSA public key of the other router.

  • At each router, specify a shared key to be used by both routers.

If you have multiple Cisco routers in a mesh topology and want to exchange IPSec traffic passing among all of those routers, you must first configure shared keys or RSA public keys among all of those routers.

Every time a new router is added to the IPSec network, you must configure keys between the new router and each of the existing routers.

Consequently, the more devices there are that require IPSec services, the more involved the key administration becomes. This approach does not scale well for larger, more complex encrypting networks.

IPSec with CAs

With a CA, you need not configure keys between all the encrypting routers. Instead, you individually enroll each participating router with the CA, requesting a certificate for the router. When this enrollment has been accomplished, each participating router can dynamically authenticate all the other participating routers.

To add a new IPSec router to the network, you need only configure that new router to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPSec routers.

IPSec with Multiple Trustpoint CAs

With multiple trustpoint CAs, you no longer have to enroll a router with the CA that issued a certificate to a peer. Instead, you configure a router with multiple CAs that it trusts. Thus, a router can use a configured CA (a trusted root) to verify certificates offered by a peer that were not issued by the same CA defined in the identity of the router.

Configuring multiple CAs allows two or more routers enrolled under different domains (different CAs) to verify the identity of each other when using IKE to set up IPSec tunnels.

Through SCEP, each router is configured with a CA (the enrollment CA). The CA issues a certificate to the router that is signed with the private key of the CA. To verify the certificates of peers in the same domain, the router is also configured with the root certificate of the enrollment CA.

To verify the certificate of a peer from a different domain, the root certificate of the enrollment CA in the domain of the peer must be configured securely in the router.

During IKE phase one signature verification, the initiator will send the responder a list of its CA certificates. The responder should send the certificate issued by one of the CAs in the list. If the certificate is verified, the router saves the public key contained in the certificate on its public key ring.

With multiple root CAs, Virtual Private Network (VPN) users can establish trust in one domain and easily and securely distribute it to other domains. Thus, the required private communication channel between entities authenticated under different domains can occur.

How IPSec Devices Use CA Certificates

When two IPSec routers want to exchange IPSec-protected traffic passing between them, they must first authenticate each other—otherwise, IPSec protection cannot occur. The authentication is done with IKE.

Without a CA, a router authenticates itself to the remote router using either RSA-encrypted nonces or preshared keys. Both methods require keys to have been previously configured between the two routers.

With a CA, a router authenticates itself to the remote router by sending a certificate to the remote router and performing some public key cryptography. Each router must send its own unique certificate that was issued and validated by the CA. This process works because the certificate of each router encapsulates the public key of the router, each certificate is authenticated by the CA, and all participating routers recognize the CA as an authenticating authority. This scheme is called IKE with an RSA signature.

Your router can continue sending its own certificate for multiple IPSec sessions and to multiple IPSec peers until the certificate expires. When its certificate expires, the router administrator must obtain a new one from the CA.

When your router receives a certificate from a peer from another domain (with a different CA), the certificate revocation list (CRL) downloaded from the CA of the router does not include certificate information about the peer. Therefore, you should check the CRL published by the configured trustpoint with the Lightweight Directory Access Protocol (LDAP) URL to ensure that the certificate of the peer has not been revoked.

To query the CRL published by the configured trustpoint with the LDAP URL, use the query url command in trustpoint configuration mode.

CA Registration Authorities

Some CAs have a registration authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.

How to Implement CA Interoperability

This section contains the following procedures:

Configuring a Router Hostname and IP Domain Name

This task configures a router hostname and IP domain name.

You must configure the hostname and IP domain name of the router if they have not already been configured. The hostname and IP domain name are required because the router assigns a fully qualified domain name (FQDN) to the keys and certificates used by IPSec, and the FQDN is based on the hostname and IP domain name you assign to the router. For example, a certificate named router20.example.com is based on a router hostname of router20 and a router IP domain name of example.com.

SUMMARY STEPS

  1. configure
  2. hostname name
  3. domain name domain-name
  4. Use the commit or end command.

DETAILED STEPS

  Command or Action Purpose

Step 1

configure

Example:


RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

hostname name

Example:


RP/0/RSP0/CPU0:router(config)# hostname myhost

Configures the hostname of the router.

Step 3

domain name domain-name

Example:


RP/0/RSP0/CPU0:router(config)# domain name mydomain.com

Configures the IP domain name of the router.

Step 4

Use the commit or end command.

commit —Saves the configuration changes and remains within the configuration session.

end —Prompts user to take one of these actions:

  • Yes — Saves configuration changes and exits the configuration session.

  • No —Exits the configuration session without committing the configuration changes.

  • Cancel —Remains in the configuration session, without committing the configuration changes.

Generating an RSA Key Pair

This task generates an RSA key pair.


Note

From Cisco IOS XR Software Release 7.0.1 and later, the crypto keys are auto-generated at the time of router boot up. Hence, step 1 is required to be configured only if the RSA host-key pair is not present in the router under some scenarios.

RSA key pairs are used to sign and encrypt IKE key management messages and are required before you can obtain a certificate for your router.

SUMMARY STEPS

  1. crypto key generate rsa [usage keys | general-keys] [keypair-label]
  2. crypto key zeroize rsa [keypair-label]
  3. show crypto key mypubkey rsa

DETAILED STEPS

  Command or Action Purpose

Step 1

crypto key generate rsa [usage keys | general-keys] [keypair-label]

Example:


RP/0/RSP0/CPU0:router# crypto key generate rsa general-keys

Generates RSA key pairs.

  • Use the usage keys keyword to specify special usage keys; use the general-keys keyword to specify general- purpose RSA keys.

  • The keypair-label argument is the RSA key pair label that names the RSA key pairs.

Step 2

crypto key zeroize rsa [keypair-label]

Example:


RP/0/RSP0/CPU0:router# crypto key zeroize rsa key1

(Optional) Deletes all RSAs from the router.

  • Under certain circumstances, you may want to delete all RSA keys from you router. For example, if you believe the RSA keys were compromised in some way and should no longer be used, you should delete the keys.

  • To remove a specific RSA key pair, use the keypair-label argument.

Step 3

show crypto key mypubkey rsa

Example:


RP/0/RSP0/CPU0:router# show crypto key mypubkey rsa

(Optional) Displays the RSA public keys for your router.

Importing a Public Key to the Router

This task imports a public key to the router.

A public key is imported to the router to authenticate the user.

SUMMARY STEPS

  1. crypto key import authentication rsa [usage keys | general-keys] [keypair-label]
  2. show crypto key mypubkey rsa

DETAILED STEPS

  Command or Action Purpose

Step 1

crypto key import authentication rsa [usage keys | general-keys] [keypair-label]

Example:


RP/0/RSP0/CPU0:router# crypto key import authentication rsa general-keys

Generates RSA key pairs.

  • Use the usage keys keyword to specify special usage keys; use the general-keys keyword to specify general- purpose RSA keys.

  • The keypair-label argument is the RSA key pair label that names the RSA key pairs.

Step 2

show crypto key mypubkey rsa

Example:


RP/0/RSP0/CPU0:router# show crypto key mypubkey rsa

(Optional) Displays the RSA public keys for your router.

Declaring a Certification Authority and Configuring a Trusted Point

This task declares a CA and configures a trusted point.

SUMMARY STEPS

  1. configure
  2. crypto ca trustpoint ca-name
  3. enrollment url CA-URL
  4. query url LDAP-URL
  5. enrollment retry period minutes
  6. enrollment retry count number
  7. rsakeypair keypair-label
  8. Use the commit or end command.

DETAILED STEPS

  Command or Action Purpose

Step 1

configure

Example:


RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

crypto ca trustpoint ca-name

Example:


RP/0/RSP0/CPU0:router(config)# crypto ca trustpoint myca

Declares a CA.

  • Configures a trusted point with a selected name so that your router can verify certificates issued to peers.

  • Enters trustpoint configuration mode.

Step 3

enrollment url CA-URL

Example:


RP/0/RSP0/CPU0:router(config-trustp)# enrollment url http://ca.domain.com/certsrv/mscep/mscep.dll

Specifies the URL of the CA.

  • The URL should include any nonstandard cgi-bin script location.

Step 4

query url LDAP-URL

Example:


RP/0/RSP0/CPU0:router(config-trustp)# query url ldap://my-ldap.domain.com

(Optional) Specifies the location of the LDAP server if your CA system supports the LDAP protocol.

Step 5

enrollment retry period minutes

Example:


RP/0/RSP0/CPU0:router(config-trustp)# enrollment retry period 2

(Optional) Specifies a retry period.

  • After requesting a certificate, the router waits to receive a certificate from the CA. If the router does not receive a certificate within a period of time (the retry period) the router will send another certificate request.

  • Range is from 1 to 60 minutes. Default is 1 minute.

Step 6

enrollment retry count number

Example:


RP/0/RSP0/CPU0:router(config-trustp)# enrollment retry count 10

(Optional) Specifies how many times the router continues to send unsuccessful certificate requests before giving up.

  • The range is from 1 to 100.

Step 7

rsakeypair keypair-label

Example:


RP/0/RSP0/CPU0:router(config-trustp)# rsakeypair mykey

(Optional) Specifies a named RSA key pair generated using the crypto key generate rsa command for this trustpoint.

  • Not setting this key pair means that the trustpoint uses the default RSA key in the current configuration.

Step 8

Use the commit or end command.

commit —Saves the configuration changes and remains within the configuration session.

end —Prompts user to take one of these actions:

  • Yes — Saves configuration changes and exits the configuration session.

  • No —Exits the configuration session without committing the configuration changes.

  • Cancel —Remains in the configuration session, without committing the configuration changes.

Authenticating the CA

This task authenticates the CA to your router.

The router must authenticate the CA by obtaining the self-signed certificate of the CA, which contains the public key of the CA. Because the certificate of the CA is self-signed (the CA signs its own certificate), manually authenticate the public key of the CA by contacting the CA administrator to compare the fingerprint of the CA certificate.

SUMMARY STEPS

  1. crypto ca authenticate ca-name
  2. show crypto ca certificates

DETAILED STEPS

  Command or Action Purpose

Step 1

crypto ca authenticate ca-name

Example:


RP/0/RSP0/CPU0:router# crypto ca authenticate myca

Authenticates the CA to your router by obtaining a CA certificate, which contains the public key for the CA.

Step 2

show crypto ca certificates

Example:


RP/0/RSP0/CPU0:router# show crypto ca certificates

(Optional) Displays information about the CA certificate.

Multi-Tier Certificate Authority for Trustpoint Authentication

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

Multi-Tier Certificate Authority for Trustpoint Authentication

Release 7.10.1

Apart from the root certificate authority (CA), you can now use a subordinate CA to issue certificates and authenticate your network devices. This feature is beneficial when you have an existing CA hierarchy where it is not the root CA but the subordinate CA that issues the leaf or router certificates.

In earlier releases, you could associate only a single CA, not a multi-tier CA, to a trustpoint. And, you could use only the root CA certificate to enroll the router certificates.

During terminal-based enrollment of a CA trustpoint, Cisco IOS XR network devices accepted only Root CA certificate. You might have some network topologies which use multi-tier CA hierarchy for enrollment purposes because it provides more flexibility and security. From Cisco IOS XR Software Release 7.10.1 and later, as part of terminal-based authentication, you can import a complete CA hierarchy (from the Root CA till the subordinate CA that issues the certificate) as part of a single authentication request. With this feature, you can provide a certificate chain including the Root CA and intermediate subordinate CAs as part of the terminal-based enrollment process. This feature is useful when you have an existing CA hierarchy where it is not the root CA but the subordinate CA that issues the leaf or router certificates.

You can have a maximum of 8 tiers, that is, a chain of CA with one Root CA and seven subordinate CAs, for trustpoint authentication.

How to Use Multi-Tier CA for Trustpoint Authentication

Use the crypto ca authenticate command to use multi-tier CAs for trustpoint authentication or enrollment. You must use only privacy enhanced mail (PEM)-encoded certificates for trustpoint authentication using multi-tier CAs.

The enrollment process remains the same as that of the enrollment using single-tier CA, except that you get a message on the router console that prompts to use only PEM-encoded certificates.

Prerequisite

You must generate a key pair, import a public key, and configure a trustpoint on the router as detailed in the previous sections.

Configuration Example

Router#crypto ca authenticate test-ca
Mon Feb  6 08:17:48.943 UTC
 
 
Enter the base 64/PEM encoded certificate/certificates.
Please note: for multiple certificates use only PEM
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----
MIIF5TCCA82gAwIBAgICEAEwDQYJKoZIhvcNAQELBQAwXTELMAkGA1UEBhMCSU4x
CzAJBgNVBAgMAktBMQwwCgYDVQQHDANCR0wxDTALBgNVBAoMBENTQ08xDTALBgNV
.
.
.
/4UzeeX6ll0gGJVbDwGeIZTH00artqxHquKQ2P7eXQ1pg0PRNRqWN90SvT5yE33N
eHgbtvdHg1K6K6IAj/NGnd7xUrA1TQ4bdmouCNkgbXM/G9DwgkOOvZ8KYRP9JW57
LYIv2ZcRS2vdnZRD9JPGVig2EgcfVPtj+Q==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIF9TCCA92gAwIBAgIUD6AGesleqedhorkrJ9HWjz1RQzswDQYJKoZIhvcNAQEL
BQAwXTELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAktBMQwwCgYDVQQHDANCR0wxDTAL
.
.
.
+6rMWd6BmfSy2PT3Qz5AjO2+3N1dd67qRRrX7skklkX4JXY42n5/l9PQtSp0wTBh
uy5yUAagynu0z07GczE7E9V+tJHRmNTbnd8pxLk4lTwqtiCIXwQLZA75SkwCS5wh
fn7OrV7uFjMaggNkvj0kSSOkWxqJ+j/KqMAA2zQMUV+qdvT6i+ZV44U=
-----END CERTIFICATE-----
Serial Number  : 10:01
  Subject:
	CN=SUB_CA_CERT,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
	CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 12:31:40 UTC Sun Jun 14 2020
  Validity End   : 12:31:40 UTC Wed Jun 12 2030

  CRL Distribution Point
	http://10.105.236.78/crl_akshath_two_level_ca/crl.der
  SHA1 Fingerprint:
	 D8E0C11ECED96F67FDBC800DB6A126676A76BD62 
  Serial Number  : 0F:A0:06:7A:C9:5E:A9:E7:61:A2:B9:2B:27:D1:D6:8F:3D:51:43:3B
  Subject:
	CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
	CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 13:12:32 UTC Sun Jun 07 2020
  Validity End   : 13:12:32 UTC Sat Jun 02 2040

  CRL Distribution Point
	http://10.105.236.78/crl_akshath_two_level_ca/crl.der
  SHA1 Fingerprint:
	 08E71248FB7578614442E713AC87C461D173952F 

CA Certificate validated using issuer certificate.
Router#
Verification

Use the show crypto ca certificates trustpoint-name to view the CA certificate chain. The command output displays the Trusted Certificate Chain field if there is one or more subordinate CAs involved in the hierarchy. 

Router#show crypto ca certificates test-ca
Mon Feb  6 09:03:53.019 UTC
 
Trustpoint       : test-ca
==================================================
CA certificate 
  Serial Number  : 10:01
  Subject:
            CN=SUB_CA_CERT,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 12:31:40 UTC Sun Jun 14 2020
  Validity End   : 12:31:40 UTC Wed Jun 12 2030
 
  CRL Distribution Point
            http://10.105.236.78/crl_akshath_two_level_ca/crl.der
  SHA1 Fingerprint:
             D8E0C11ECED96F67FDBC800DB6A126676A76BD62 
Trusted Certificate Chain
  Serial Number  : 0F:A0:06:7A:C9:5E:A9:E7:61:A2:B9:2B:27:D1:D6:8F:3D:51:43:3B
  Subject:
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 13:12:32 UTC Sun Jun 07 2020
  Validity End   : 13:12:32 UTC Sat Jun 02 2040
 
  CRL Distribution Point
            http://10.105.236.78/crl_akshath_two_level_ca/crl.der
  SHA1 Fingerprint:
             08E71248FB7578614442E713AC87C461D173952F 
Router certificate
  Key usage      : General Purpose 
  Status         : Available 
  Serial Number  : 28:E5
  Subject:
            CN=test
  Issued By      :
            CN=SUB_CA_CERT,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 08:49:54 UTC Mon Feb 06 2023
  Validity End   : 08:49:54 UTC Wed Mar 08 2023
  SHA1 Fingerprint:
             6C8644FA67D9CEBC7C5665C35838265F578835AB 
Associated Trustpoint: test-ca

Requesting Your Own Certificates

This task requests certificates from the CA.

You must obtain a signed certificate from the CA for each of your router’s RSA key pairs. If you generated general-purpose RSA keys, your router has only one RSA key pair and needs only one certificate. If you previously generated special usage RSA keys, your router has two RSA key pairs and needs two certificates.

SUMMARY STEPS

  1. crypto ca enroll ca-name
  2. show crypto ca certificates

DETAILED STEPS

  Command or Action Purpose

Step 1

crypto ca enroll ca-name

Example:


RP/0/RSP0/CPU0:router# crypto ca enroll myca

Requests certificates for all of your RSA key pairs.

  • This command causes your router to request as many certificates as there are RSA key pairs, so you need only perform this command once, even if you have special usage RSA key pairs.

  • This command requires you to create a challenge password that is not saved with the configuration. This password is required if your certificate needs to be revoked, so you must remember this password.

  • A certificate may be issued immediately or the router sends a certificate request every minute until the enrollment retry period is reached and a timeout occurs. If a timeout occurs, contact your system administrator to get your request approved, and then enter this command again.

Step 2

show crypto ca certificates

Example:


RP/0/RSP0/CPU0:router# show crypto ca certificates

(Optional) Displays information about the CA certificate.

Configuring Certificate Enrollment Using Cut-and-Paste

This task declares the trustpoint certification authority (CA) that your router should use and configures that trustpoint CA for manual enrollment by using cut-and-paste.

SUMMARY STEPS

  1. configure
  2. crypto ca trustpoint ca-name
  3. enrollment terminal
  4. Use the commit or end command.
  5. crypto ca authenticate ca-name
  6. crypto ca enroll ca-name
  7. crypto ca import ca- name certificate
  8. show crypto ca certificates

DETAILED STEPS

  Command or Action Purpose

Step 1

configure

Example:


RP/0/RSP0/CPU0:router# configure

Enters global configuration mode.

Step 2

crypto ca trustpoint ca-name

Example:

 RP/0/RSP0/CPU0:router(config)# crypto ca trustpoint myca RP/0/RSP0/CPU0:router(config-trustp)#

Declares the CA that your router should use and enters trustpoint configuration mode.

  • Use the ca-name argument to specify the name of the CA.

Step 3

enrollment terminal

Example:

 RP/0/RSP0/CPU0:router(config-trustp)# enrollment terminal

Specifies manual cut-and-paste certificate enrollment.

Step 4

Use the commit or end command.

commit —Saves the configuration changes and remains within the configuration session.

end —Prompts user to take one of these actions:

  • Yes — Saves configuration changes and exits the configuration session.

  • No —Exits the configuration session without committing the configuration changes.

  • Cancel —Remains in the configuration session, without committing the configuration changes.

Step 5

crypto ca authenticate ca-name

Example:

 RP/0/RSP0/CPU0:router# crypto ca authenticate myca

Authenticates the CA by obtaining the certificate of the CA.

  • Use the ca-name argument to specify the name of the CA. Use the same name that you entered in Step 2.

Step 6

crypto ca enroll ca-name

Example:

 RP/0/RSP0/CPU0:router# crypto ca enroll myca

Obtains the certificates for your router from the CA.

  • Use the ca-name argument to specify the name of the CA. Use the same name that you entered in Step 2.

Step 7

crypto ca import ca- name certificate

Example:

 RP/0/RSP0/CPU0:router# crypto ca import myca certificate

Imports a certificate manually at the terminal.

  • Use the ca-name argument to specify the name of the CA. Use the same name that you entered in Step 2.

Note

 

You must enter the crypto ca import command twice if usage keys (signature and encryption keys) are used. The first time the command is entered, one of the certificates is pasted into the router; the second time the command is entered, the other certificate is pasted into the router. (It does not matter which certificate is pasted first.)

Step 8

show crypto ca certificates

Example:

 RP/0/RSP0/CPU0:router# show crypto ca certificates

Displays information about your certificate and the CA certificate.

Configuration Examples for Implementing Certification Authority Interoperability

This section provides the following configuration example:

Configuring Certification Authority Interoperability: Example

The following example shows how to configure CA interoperability.

Comments are included within the configuration to explain various commands.


configure
hostname myrouter
domain name mydomain.com
end

Uncommitted changes found, commit them? [yes]:yes

crypto key generate rsa mykey

The name for the keys will be:mykey
Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keypair
Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [1024]:
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

show crypto key mypubkey rsa

Key label:mykey
Type     :RSA General purpose
Size     :1024
Created  :17:33:23 UTC Thu Sep 18 2003
Data     :
 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CB8D86 
 BF6707AA FD7E4F08 A1F70080 B9E6016B 8128004C B477817B BCF35106 BC60B06E 
 07A417FD 7979D262 B35465A6 1D3B70D1 36ACAFBD 7F91D5A0 CFB0EE91 B9D52C69 
 7CAF89ED F66A6A58 89EEF776 A03916CB 3663FB17 B7DBEBF8 1C54AF7F 293F3004 
 C15B08A8 C6965F1E 289DD724 BD40AF59 E90E44D5 7D590000 5C4BEA9D B5020301 
 0001

! The following commands declare a CA and configure a trusted point.

configure
crypto ca trustpoint myca
enrollment url http://xyz-ultra5
enrollment retry count 25
enrollment retry period 2
rsakeypair mykey
end

Uncommitted changes found, commit them? [yes]:yes

! The following command authenticates the CA to your router.

crypto ca authenticate myca

Serial Number  :01
Subject Name   :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Issued By      :
cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
Validity Start :07:00:00 UTC Tue Aug 19 2003
Validity End   :07:00:00 UTC Wed Aug 19 2020
Fingerprint:58 71 FB 94 55 65 D4 64 38 91 2B 00 61 E9 F8 05 
Do you accept this certificate?? [yes/no]:yes

! The following command requests certificates for all of your RSA key pairs.

crypto ca enroll myca

% Start certificate enrollment ... 
% 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:
Re-enter Password:
    Fingerprint: 17D8B38D ED2BDF2E DF8ADBF7 A7DBE35A 

! The following command displays information about your certificate and the CA certificate.

show crypto ca certificates

Trustpoint       :myca
==========================================================
CA certificate 
  Serial Number  :01
  Subject Name   :
        cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
  Issued By      :
        cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
  Validity Start :07:00:00 UTC Tue Aug 19 2003
  Validity End   :07:00:00 UTC Wed Aug 19 2020
Router certificate
  Key usage      :General Purpose 
  Status         :Available 
  Serial Number  :6E
  Subject Name   :
        unstructuredName=myrouter.mydomain.com,o=Cisco Systems
  Issued By      :
        cn=Root coax-u10 Certificate Manager,ou=HFR,o=Cisco Systems,l=San Jose,st=CA,c=US
  Validity Start :21:43:14 UTC Mon Sep 22 2003
  Validity End   :21:43:14 UTC Mon Sep 29 2003
  CRL Distribution Point
        ldap://coax-u10.cisco.com/CN=Root coax-u10 Certificate Manager,O=Cisco Systems

Expiry Notification for PKI Certificate

The section provides information about the notification mechanism using SNMP trap and syslog messages when a public key infrastructure (PKI) certificate is approaching its expiry date.

Learn About the PKI Alert Notification

Security is critical and availability of certificates for applications is vital for authenticating the router. If the certificate expires, they become invalid and impacts services like Crosswork Trust Insights, Internet Key Exchange version 2, dot1x, and so on.

What if there is a mechanism to alert the user about the expiry date of the certificate?

From Release 7.1.1, IOS -XR provides a mechanism by which a CA client sends a notification to a syslog server when certificates are on the verge of expiry. Alert notifications are sent either through the syslog server or Simple Network Management Protocol (SNMP) traps.

PKI traps retrieves the certificate information of the devices in the network. The device sends SNMP traps at regular intervals to the network management system (NMS) based on the threshold configured in the device.

An SNMP trap (certificate expiry notification) is sent to the SNMP server at regular intervals starting from 60 days to one week before the certificate end date. The notifications are sent at the following intervals:

The notifications are sent at the following intervals:

Intervals

Description

Notification Mode

First notification

The notification is sent 60 days before the expiry of the certificate.

The notificiation are in a warning mode.

Repeated notifications

The repeated notification is sent every week, until a week before the expiry of the certificate.

The notifications are in a warning mode when the certificate is valid for more than a week.

The notifications are in a warning mode when the certificate is valid for more than a week.

Last notification

The notifications are sent every day until the certificate expiry date.

The notifications are in an alert mode when the validity of a certificate is less than a week.

The notifications include the following information:

  • Certificate serial number

  • Certificate issuer name

  • Trustpoint name

  • Certificate type

  • Number of days remaining for the certificate to expire

  • Certificate subject name

The following is a syslog message that is displayed on the device:

%SECURITY-CEPKI-1-CERT_EXPIRING_ALERT : Certificate expiring WITHIN A WEEK. 
Trustpoint Name= check, Certificate Type= ID, Serial Number= 02:EC, 
Issuer Name= CN=cacert,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN, Subject name= CN=cisco.com, 
Time Left= 1 days, 23 hours, 59 minutes, 41 seconds

Restrictions for PKI Credentials Expiry Alerts

Alerts are not sent for the following certificates:

  • Secure Unique Device Identifier (SUDI) certificates

  • Certificates that belong to a trustpool. Trustpools have their own expiry alerts mechanism

  • Trustpoint clones

  • CA certificates that do not have a router certificate associated with it.

  • Certificates with key usage keys

Enable PKI Traps

This feature cannot be disabled and requires no additional configuration tasks.

To enable PKI traps, use the snmp-server traps pki command. If SNMP is configured, the SNMP trap is configured in the same PKI expiry timer. 


Router(config)# snmp-server traps pki
Router(config)# commit

Verification

This example shows sample output from the show running-config command.
Router# show runn snmp-server traps
snmp-server traps pki

What’s Next: See Regenerate the Certificate.

Regenerate the Certificate

The certificate becomes invalid once expired. When you see the certificate expiry notification, we recommend you to regenerate the certificate, as soon as possible.

Perform the following steps, to regenerate the certificates:

  1. Clear the existing certificate using the following command:

    Router# clear crypto ca certificates [trustpoint-name]

    For example,

    Router# clear crypto ca certificates myca

  2. We recommend you to regenerate a new keypair for the label configured under the trustpoint-name. The new keypair overwrites the old key pair. 

    Router# crypto key generate rsa [keypair-lablel]

    For example,

    Router# crypto key generate rsa mykey
The name for the keys will be: mykey
% You already have keys defined for mykey
Do you really want to replace them? [yes/no]: yes
  Choose the size of the key modulus in the range of 512 to 4096 for your General Purpose Keypair. Choosing a key modulus greater than 512 may take a few minutes.
 
How many bits in the modulus [2048]: 
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]The name for the keys will be: mykey
% You already have keys defined for mykey
Do you really want to replace them? [yes/no]: yes
  Choose the size of the key modulus in the range of 512 to 4096 for your General Purpose Keypair. Choosing a key modulus greater than 512 may take a few minutes.
 
How many bits in the modulus [2048]: 
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

  3. Reenroll the certificate using the following command. For more information, see Requesting Your Own Certificates. 

    
Router# crypto ca authenticate [trustpoint-name]
Router# crypto ca enroll [trustpoint-name]

    For example,

    
Router# crypto ca authenticate myca
Router# crypto ca enroll myca

Automatic renewal of PKI certificate

Table 2. Feature History Table

Feature Name

Release Information

Feature Description

Automatic renewal of Public Key Infrastructure (PKI) certificate

Release 7.5.3

You can now enable the router to renew the PKI certificate from the Certificate Authority (CA) by configuring the percentage of the certificate validity, after which the router requests a new certificate from the CA, and the CA authorizes it before certification expiration. This feature eliminates the previously needed manual efforts of certification renewal and avoids interruptions such as MACsec session flaps due to certificate expiry and so on.

This feature introduces the following commands:

The public key infrastructure (PKI) controls the digital certificates that protect the sensitive information flowing through a network to provide secure end-to-end communication. The PKI encrypts and decrypts data using a public key and a private key pair that it generates. A PKI (digital) certificate is a digital entity used to authenticate the identity of a router. These PKI certificates often have a short validity time and would need manual efforts from the network operators to replace them in time.

With automatic renewal of PKI certificate, the router has an ability to automatically renew the PKI certificate when it is approaching its expiry date. Here, you can configure a timeline for the PKI certificate renewal. You can specify the percentage of certificate validity, after which you would prefer the router to request a new certificate from the CA server. This timeline for auto-renewal of the PKI certificate is called auto-enroll. When a router with auto-enroll configured completes the said period, the router will generate a certificate signing request and sends the request to the CA using Simple Certificate Management Protocol (SCMP). The CA server will immediately create a newly signed certificate and ensures that it replaces the old certificate in the router. This way, automatic renewal of the PKI certificate before expiry avoids any interruptions to data flowing through the network.

Figure 1. Automatic renewal of Public Key Infrastructure (PKI) certificate

Pre-requisites

  • Ensure that the CA has a valid certificate.

  • Make sure that the CA possess certificate renewal capability.

  • You must configure a trustpoint in the router. Configure the trustpoint using crypto ca trustpoint command.


    Note

    A trustpoint should be authenticated before any enrolment. The trustpoint is authenticated when it has a CA certificate, and it is enrolled when it has a router certificate.

  • The communication between the PKI Client and CA server should be over HTTP protocol. That is, the enrollment url for CA server should a HTTP url.

Configuration Guidelines

  • The PKI certificates are signed using the RSA algorithm only.

  • If you configure the auto-enroll option under trustpoint after the renew timer for a PKI certificate has started, then such configuration will only apply to the next renewal cycle and not the current one. The same condition applies while configuring the no auto-enroll option as well.

  • The auto-enroll percentage may range between 1 and 99.

  • The certificate renewal process requires the serial number and IP address values in the trustpoint. If these values are readily available under the trustpoint, the renewal process obtains it from there. If not, the router CLI requests you to configure these values during trustpoint enrollment.

  • By default, the PKI uses PKCS requests for automatic certification renewal. You can also configure the router to use the Renewal request by executing the renewal-message-type renewalreq command.

  • If the CA server is unable to address the certificate renewal requests, it requests the router to poll the renewal request. In such scenarios, by default, the router retries for 10 minutes with a gap of 1 minute between each request if a certificate renewal attempt fails. You can also configure these values using the enrollment retry count and enrollment retry period commands.

Configuration Example

Configuration

Configuring this feature using the CLI:

Router# configure
Router(config)# crypto ca trustpoint test
Router(config-trustp)# enrollment url http://frog.phoobin.com
Router(config-trustp)# subject-name OU=Spiral Dept., O=tiedye.com
Router(config-trustp)# auto-enroll 30
Router(config-trustp)# commit

To disable this feature, execute the following:

Router# configure
Router(config)# no auto-enroll
Router(config-trustp)# commit

Running configuration

Router# show running-config crypto ca trustpoint test
crypto ca trustpoint test
 enrollment url http://frog.phoobin.com
 auto-enroll 30
!

Integrating Cisco IOS XR and Crosswork Trust Insights

The Cisco IOS XR 64-bit Software provides you the infrastructure to enroll and share the signed-data with Cisco Crosswork cloud infrastructure and applications. The Cisco Crosswork Trust Insights is a cloud-based Software as a service (SaaS) that provides signed and encrypted system integrity information to track the trust posture of network hardware and software components. For details, see Cisco Crosswork Trust Insights Data Sheet.

Integrating IOS XR and Crosswork Trust Insights include these main processes:

  • System enrollment – Enrolling a Cisco IOS XR platform into Crosswork cloud infrastructure.

  • Signed-data sharing – Sharing the data for infrastructure trust analysis between the systems that run IOS XR and Crosswork. This involves collecting the signed-data dossier, that is, signed-data that is needed for infrastructure trust inspection service.

Workflow

The following steps depict the workflow of Cisco IOS XR and Crosswork Trust Insights integration:

  1. As part of the enrollment process, the user generates new key pair and trust root within the IOS XR system by using the IOS XR commands.

  2. The user logs into the Trust Inspector service, and enters the enrollment workflow in the enrollment dialog to create a new device ID. The user must provide the management IP address, login credentials and certificate root to the Trust Inspector service.

  3. The Trust Inspector service configures the Crosswork collector to log in to the router, and to pull the data that is pushed down from the cloud to the collector

    .

  4. The Crosswork collector begins a periodic polling cycle and executes a command to generate a signed-information dossier from each IOS XR instance that is being polled.

  5. The collector forwards the signed-envelope data to the cloud service for validation.

  6. The cloud service validates signed-envelope against the enrolled certificate or trust chain.

How to Integrate Cisco IOS XR and Crosswork Trust Insights

Integrating Cisco IOS XR and Crosswork Trust Insights involve these main tasks for system enrollment and signed-data sharing:

For details of IOS XR commands used in this configuration, see the Public Key Infrastructure Commands chapter in the System Security Command Reference for Cisco ASR 9000 Series Routers.

Prerequisites

Before you begin, you must check here for any available IOS XR Software Maintenance Updates (SMUs) specific to Crosswork Trust Insights. For information related to SMUs, see Cisco IOS XR Release Notes.

You must ensure that the below configurations are present on the IOS XR device, before starting IOS XR and Crossworks Trust Insights integration.

  • User authorization required to collect the signed-data dossier

  • SSH server configuration

  • Netconf server configuration

  • Domain name configuration, which is required for certification enrollment

The sections given below lists the configuration example for the prerequisites.

Configuration Example for User Authorization

You must have the required user access privileges in order to collect the data dossier from the system. This is defined in terms of IOS XR Task IDs for each command.

For the respective Task ID applicable for each data dossier option and for the signed-envelope, see the Task ID section in the Command Reference page of show platform security integrity dossier command and utility sign command.

Listed below are the configurations to set up a user with sufficient authorization to collect all the signed-data dossier. You can configure customized task groups, then associate those task groups with user groups, and finally associate the user groups with the user.

Note

We recommend that you use the task execute dossier to configure a CTI (customer-define) user, who collects dossier from the system. 


Router#configure
Router(config)#taskgroup alltasks-dossier
Router(config-tg)#task read sysmgr
Router(config-tg)#task read system
Router(config-tg)#task read pkg-mgmt
Router(config-tg)#task read basic-services
Router(config-tg)#task read config-services
Router(config-tg)#task execute dossier 
Router(config-tg)#task execute basic-services
Router(config-tg)#commit

Router#configure
Router(config)#usergroup dossier-group
Router(config-ug)#taskgroup alltasks-dossier
Router(config-ug)#commit


Router#configure
Router(config)#username dossier-user
Router(config-un)#group dossier-group
Router(config-un)#commit

Configuration Example for SSH and Netconf


Router#configure
Router(config)#ssh server v2
Router(config)#ssh server vrf default
Router(config)#ssh server netconf vrf default
Router(config)#netconf-yang agent
Router(config-ncy-agent)#ssh
Router(config-ncy-agent)#exit
Router(config)#domain name example.com
Router(config)#commit

Running Configuration for SSH and Netconf


ssh server v2
ssh server vrf default
ssh server netconf vrf default
!
netconf-yang agent
 ssh
!
domain name example.com

While the dossier is collected from a device through SSH, the SSH session might timeout. Also, multiple ssh sessions to a device can result in the denial of some SSH sessions. To avoid such occurrence, the following configuration is recommended on the device: 


Router#configure
Router(config)#ssh server rate-limit 600
Router(config)#line default
Router(config-line)#exec-timeout 0 0
Router(config-line)#session-timeout 0
Router(config-line)#commit

Running Configuration


ssh server rate-limit 600
!
line default
 exec-timeout 0 0
 session-timeout 0
!

Generate Key Pair

To enroll a system running Cisco IOS XR Software, you must generate the key and the certificate for both the leaf and the root node. The system supports a two tier self-signed certificate chain for the enrollment key to support re-keying without re-enrollment of the certificate with the Crossworks service.

You can use the system-root-key and system-enroll-key options in the crypto key generate command to generate the root key and the enrollment key respectively, for all the hashing algorithms. You can do this for hashing algorithms such as RSA, DSA or ECDSA (including ECDSA nistp384 and ECDSA nitsp521).

Example of Generating Key Pair

Key pair generation for root:


Router#crypto key generate rsa system-root-key

Sun Oct 20 13:05:26.657 UTC
The name for the keys will be: system-root-key
Choose the size of the key modulus in the range of 512 to 4096 for your General Purpose Keypair. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [2048]:
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

Key pair generation for leaf:


Router#crypto key generate rsa system-enroll-key

Sun Oct 20 13:05:40.370 UTC
The name for the keys will be: system-enroll-key
Choose the size of the key modulus in the range of 512 to 4096 for your General Purpose Keypair. Choosing a key modulus greater than 512 may take a few minutes.
 How many bits in the modulus [2048]:
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

Verification

You can use the show crypto key mypubkey rsa command to verify the above key pair generation. 


Router#show  crypto  key mypubkey rsa | begin system-
Fri Mar 27 14:00:20.954 IST
Key label: system-root-key
Type     : RSA General purpose
Size     : 2048
Created  : 01:13:10 IST Thu Feb 06 2020
Data     : 
 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101 
 00A93DE0 1E485EE3 0E7F0964 C48361D1 B6014BE7 A303D8D6 F7790E92 88E69C4B 
 B97B7A9C D1B277E3 1569093C 82BD3258 7F67FB49 94860ECD 34498F1F 59B45757 
 F32C8E8F 7CEE23EC C36A43D1 9F85C0D9 B96A14DD DD3BBD4C A1FB0888 EED210A7 
 39D9A403 7ACE0F6E 39107226 CA621AD8 6E8102CA 9761B86F D33F2871 9DD16559 
 AFCB4729 EFCEDBAF 83DF76E4 9A439844 EE3B1180 4022F575 99E11A2C E25BB23D 
 9DD74C81 4E5C1345 D9E3CC79 1B98B1AA 6C06F004 22B901EC 36C099FE 10DE2622 
 EB7CE618 9A555769 12D94C90 D9BEE5EA A664E7F6 4DF8D8D4 FE7EAB07 1EF4FEAB 
 22D9E55F 62BA66A0 72153CEC 81F2639F B5F2B5C5 25E10364 19387C6B E8DB8990 
 11020301 0001
 
Key label: system-enroll-key
Type     : RSA General purpose
Size     : 2048
Created  : 01:13:16 IST Thu Feb 06 2020
Data     : 
 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101 
 009DBC14 C83604E4 EB3D3CF8 5BA7FDDB 80F7E85B 427332D8 BBF80148 F0A9C281 
 49F87D5C 0CEBA532 EBE797C5 7F174C69 0735D13A 493670CB 63B04A12 4BCA7134 
 EE0031E9 047CAA1E 802030C5 6071E8C2 F8ECE002 CC3B54E7 5FD24E5C 61B7B7B0 
 68FA2EFA 0B83799F 77AE4621 435D9DFF 1D713108 37B614D3 255020F9 09CD32E8 
 82B07CD7 01A53896 6DD92B5D 5119597C 98D394E9 DBD1ABAF 6DE949FE 4A8BF1E7 
 851EB3F4 60B1114A 1456723E 063E50C4 2D410906 BDB7590B F1D58480 F3FA911A 
 6C9CD02A 58E68D04 E94C098F 0F0E81DB 76B40C55 64603499 2AC0547A D652412A 
 BCBBF69F 76B351EE 9B2DF79D E490C0F6 92D1BB97 B905F33B FAB53C20 DDE2BB22 
 C7020301 0001

Associated Commands

  • crypto key generate dsa

  • crypto key generate ecdsa

  • crypto key generate rsa

  • show crypto key mypubkey dsa

  • show crypto key mypubkey ecdsa

  • show crypto key mypubkey rsa

Generate System Trust Point for the Leaf and Root Certificate

You must configure these steps to generate the system trust point for the root and the leaf certificate:

Configuration Example


Router#config
Router(config)#domain name domain1
Router(config)#crypto ca trustpoint system-trustpoint
Router(config)#keypair rsa system-enroll-key
Router(config)#ca-keypair rsa system-root-key
Router(config)#subject-name CN=lab1-ads,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
Router(config)#subject-name ca-certificate CN=lab1-ca,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
Router(config)#enrollment url self
Router(config)#key-usage certificate digitalsignature keyagreement dataencipherment
Router(config)#lifetime certificate 300
Router(config)#message-digest sha256
Router(config)#key-usage ca-certificate digitalsignature keycertsign crlsign
Router(config)#lifetime ca-certificate 367
Router(config)#commit

Running Configuration


config
domain name domain1
crypto ca trustpoint system-trustpoint
keypair rsa system-enroll-key
ca-keypair rsa system-root-key
subject-name CN=lab1-ads,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
subject-name ca-certificate CN=lab1-ca,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
enrollment url self
key-usage certificate digitalsignature keyagreement dataencipherment
lifetime certificate 300
message-digest sha256
key-usage ca-certificate digitalsignature keycertsign crlsign
lifetime ca-certificate 367
!

Associated Commands

  • ca-keypair
  • crypto ca trustpoint
  • domain
  • enrollment
  • key-usage
  • key-pair
  • lifetime
  • message-digest
  • subject-name

Generate Root and Leaf Certificates

You must perform these steps to generate the root and the leaf certificates.

The root certificate is self-signed. The root certificate signs the leaf certificate.

Example of Generating Root Certificate


Router#crypto ca authenticate system-trustpoint

Sun Oct 20 13:07:24.136 UTC
% The subject name in the certificate will include: CN=lab1
ca,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
% The subject name in the certificate will include: ios.cisco.com
Serial Number  : 0B:62
Subject:
serialNumber=c44a11fc,unstructuredName=ios.cisco.com,OU=ASR,O=cisco systems,L=San Jose,ST=CA,C=US,CN=lab1-ca
Issued By      :
        serialNumber=c44a11fc,unstructuredName=ios.cisco.com,OU=ASR,O=cisco systems,L=San Jose,ST=CA,C=US,CN=lab1-ca
  Validity Start : 13:07:26 UTC Sun Oct 20 2019
  Validity End   : 13:07:26 UTC Wed Oct 21 2020
  SHA1 Fingerprint:
         9DD50A6B24FEBC1DDEE40CD2B4D99A829F260967

Example of Generating Leaf Certificate


Router#crypto ca enroll system-trustpoint

Sun Oct 20 13:07:45.593 UTC
% The subject name in the certificate will include: CN=lab1-ads,C=US,ST=CA,L=San Jose,O=cisco systems,OU=ASR
% The subject name in the certificate will include: ios.cisco.com
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: c44a11fc
% Include an IP address in the subject name? [yes/no]: no
Certificate keypair configured Type: 1, Label: system-enroll-key.Leaf cert key usage string: critical,digitalSignature,keyEncipherment,keyAgreement.  Serial Number  : 0B:63
  Subject:
        serialNumber=c44a11fc,unstructuredName=ios.cisco.com,OU=ASR,O=cisco systems,L=San Jose,ST=CA,C=US,CN=lab1-ads
  Issued By      :
        serialNumber=c44a11fc,unstructuredName=ios.cisco.com,OU=ASR,O=cisco systems,L=San Jose,ST=CA,C=US,CN=lab1-ca
  Validity Start : 13:07:47 UTC Sun Oct 20 2019
  Validity End   : 13:07:47 UTC Sat Aug 15 2020
  SHA1 Fingerprint:
         19D4C40F9EFF8FF25B59DE0161BA6C0706DC9E3A

Verification

You can use the show crypto ca certificates system-trustpoint [detail] command to see the details of generated root and leaf certificates: 


Router#show crypto ca certificates system-trustpoint  
Fri Mar 27 14:00:51.037 IST

Trustpoint       : system-trustpoint
==================================================
CA certificate 
  Serial Number  : 10:B5
  Subject:
        serialNumber=7b20faa4,unstructuredName=test-sec1.cisco.com
  Issued By      :
        serialNumber=7b20faa4,unstructuredName=test-sec1.cisco.com
  Validity Start : 12:30:17 UTC Fri Feb 21 2020
  Validity End   : 12:30:17 UTC Sat Feb 20 2021
  SHA1 Fingerprint:
         9400A30816805219FAAA5B9C86C214E6F34CEF7B 
Router certificate
  Key usage      : General Purpose 
  Status         : Available 
  Serial Number  : 10:B6
  Subject:
        serialNumber=7b20faa4,unstructuredAddress=10.1.1.1,unstructuredName=test-sec1.cisco.com,CN=Anetwork,OU=IT,O=Spark Network,L=Rotterdam,ST=Zuid Holland,C=NL
  Issued By      :
        serialNumber=7b20faa4,unstructuredName=test-sec1.cisco.com
  Validity Start : 12:30:31 UTC Fri Feb 21 2020
  Validity End   : 12:30:31 UTC Sat Feb 20 2021
  SHA1 Fingerprint:
         21ACDD5EB6E6F4103E02C1BAB107AD86DDCDD1F3 
Associated Trustpoint: system-trustpoint

Associated Commands

  • crypto ca authenticate

  • crypto ca enroll

  • show crypto ca certificates system-trustpoint

System Certificates Expiry

You need to regenerate the certificate, before it expires. From Release 7.1.1, IOS -XR provides a mechanism by which a CA client sends a notification to a syslog server when certificates are on the verge of expiry. For more information see Learn About the PKI Alert Notification.

When you see the certificate expiry notification, we recommend you to regenerate the certificate, see Regenerate the Certificate.

The following example shows how to regenerate the certificate.

Router# clear crypto ca certificates system-trustpoint
Router# crypto ca authenticate system-trustpoint
Router# crypto ca enroll system-trustpoint

Collect Data Dossier

Table 3. Feature History Table

Feature Name

Release Information

Description

Collect Filesystem Inventory

Release 7.3.1

With this feature, a snapshot of the filesystem metadata such as when the file was created, modified, or accessed is collected at each configured interval.

In addition to displaying the changes that the file underwent as compared to the previous snapshot, the inventory helps in maintaining data integrity of all the files in the system.

IMA Optimization

Release 7.3.1

Integrity Measurement Architecture (IMA) is a Linux-based utility that attests and appraises the integrity of a system security, at runtime. In this release, IMA introduces the following IMA optimization aspects:

  • Incremental IMA that collects IMA events selectively and progressively instead of collecting all the IMA events at the same time. You can define the start of an IMA sequence, which consists of start event, start sequence number, and start time.

  • SUDI Signature - provides the hardware root of trust to the dossier that is collected by the system.

Support for Display Compact Option

Release 7.4.1

This release introduces:

  • The display compact option in the dossier CLI. The dossier contains all the fields of the IMA events, thus making the file size very heavy. With the display compact option, the system allows you to obtain IMA event logs in the protobuf format, which can then be decoded at the client end.

The display compact option is added to the show platform security integrity dossier include system-integrity-snapshot command.

The Cisco IOS XR Software provides a data dossier command, show platform security integrity dossier , that helps in collecting the data from various IOS XR components. The output is presented in JSON format.

You can choose various selectors for this command as given below:


Router#show platform security integrity dossier include packages reboot-history rollback-history system-integrity-snapshot filesystem-inventory system-inventory nonce 1580 | utility sign nonce 1580 include-certificate

Create Signed-Envelope

To verify the data integrity and authenticity of the data dossier output, a signature is added to the output data. To enable this feature, you can use the utility sign command along with the show platform security integrity dossier command. The output is presented in JSON format.

This utility sign can also be used with any of the IOS XR commands.


Note

The Secure Unique Device Identifier or SUDI signature provides the hardware root of trust to the dossier that is collected by the system.

Verification Example of Collecting Data Dossier and Creating Signed-Envelope


Router#show  platform security integrity  dossier include  reboot-history nonce 1580 | utility sign nonce 1580 include-certificate

Fri Mar 27 15:20:58.010 IST
{
 "cli-output": "{\"collection-start-time\":1585302658.0980761,\"model-name\":\"http://cisco.com/ns/yang/Cisco-IOS-XR-ama\",\"model-revision\":\"2019-08-05\",\"license-udi\":{\"result-code\": \"Success\", \"license-udi\": \"UDI: PID:NCS-5501-SE,SN:FOC2107R0ZB\\n\"},\"version\":{\"result-code\": \"Success\", \"version\": \"Cisco IOS XR Software, Version 7.0.1.26I\\nCopyright (c) 2013-2020 by Cisco Systems, Inc.\\n\\nBuild Information:\\n Built By     : labuser\\n Built On     : Wed Mar 11 20:46:36 PDT 2020\\n 
Built Host   : iox-ucs-009\\n Workspace    : /auto/iox-ucs-009-san2/prod/7.0.1.26I.DT_IMAGE/asr9000/ws\\n Version      : 7.0.1.26I\\n Location     : /opt/cisco/XR/packages/\\n Label        : 7.0.1.26I\\n\\ncisco ASR 9000 () processor\\nSystem uptime is 1 week 3 days 19 hours 58 minutes\\n\\n\"},\"platform\":{\"result-code\": \"Success\", \"platform\": \"Node              Type                       State             Config state\\n------------------------------------------------------------------------------
--\\n0/RP0/CPU0        ASR-9000-SE(Active)        IOS XR RUN        NSHUT\\n0/RP0/NPU0        Slice                      UP                \\n0/FT0             NCS-1RU-FAN-FW             OPERATIONAL       NSHUT\\n0/FT1             NCS-1RU-FAN-FW             OPERATIONAL       NSHUT\\n0/PM0             NCS-1100W-ACFW             FAILED            NSHUT\\n0/PM1             NCS-1100W-ACFW             OPERATIONAL       NSHUT\\n\"},\"reboot-history\":{\"result-code\":\"Success\",\"model-name\":\"Cisco-IOS-XR-linu
x-os-reboot-history-oper\",\"model-revision\":\"2019-04-05\",\"node\":[{\"node-name\": \"0/RP0/CPU0\", \"reboot-history\": [{\"reason\": \"User initiated graceful reload\", \"time\": \"Wed Feb 19 15:25:11 2020\", \"cause-code\": 1, \"no\": 1}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Wed Feb 19 16:38:00 2020\", \"cause-code\": 37, \"no\": 2}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Wed Feb 19 19:06:27 2020\", \"cause-code\": 37, \"no\": 3}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Thu Feb 20 11:50
:50 2020\", \"cause-code\": 37, \"no\": 4}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Fri Feb 21 10:54:09 2020\", \"cause-code\": 37, \"no\": 5}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Fri Feb 21 19:00:10 2020\", \"cause-code\": 37, \"no\": 6}, {\"reason\": \"CARD_SHUTDOWN\", \"time\": \"Sun Feb 23 12:05:25 2020\", \"cause-code\": 37, \"no\": 7}, {\"reason\": \"User initiated graceful reload\", \"time\": \"Mon Mar  2 19:03:25 2020\", \"cause-code\": 241, \"no\": 8}, {\"reason\": \"CARD_SHUTDOWN\", \"
time\": \"Mon Mar  2 19:08:16 2020\", \"cause-code\": 37, \"no\": 9}]}]},\"collection-end-time\":1585302661.316119}",
 "signature-envelop": {
  "nonce": "1580",
  "signature-version": "01",
  "digest-algorithm": "RSA-SHA256",
  "pub-key-id": "4278",
  "signature": "ZEKkhGKqZZifp3m6v/6O69MvXN+o9x+6vp9DnzO8YwaMdd59ORVRck9UoqWGd9JB9wfK9B7eMN+UvhCqBRwgw==",
  "sudi-signature": "UogQoTKcJ5FFHQ3VYIBjYTelQax5b/I5yHcGL2xjw0HE27vtc7d2OQ7dC3rAljtkrlEZduAKHxhmkMoakR
Grp7gl+5PfsSeXdEMG3kaaKja3isPsyX2/EaBr3bw3SzUHaFicY3MPESS4FwdOpfVbEwe+AR+CB9lDnbl4Izwo0zDTw4M41SWkZZmgHVMXgVf
jwPiVYONdFVTift7rfoIoMVUoYkRbQYiFPGxMjgNcixfDqGjXoTt+hen4IRbvvRz653qgWVvS+TEgcU/nBVvkX1itNR5uGeh/Vcs8dbpBPixh
afZEfwWI8G2WQClfC0q+O+ggfn8ln9UW6exNKQZb2Q==",
"signing-certificate": [ "MIIDLjCCAhagAwIBAwICELUwDQYJKoZIhvcNAQELBQAwODEjMCEGCSqGSIb3DQEJAhYUdHVya
Z/tJlIYOzTRJjx9ZtFdX8yyOj3zuI+zDakPRn4XA2blqFN3dO71MofsIiO7SEKc52aQDes4PbjkQcibKYhrYboECypdhuG/TPyhxndFlWa/
ZnhGiziW7I9nddMgU5cE0XZ48x5G5ixqmwG8AQiuQHsNsCZ/hDeJiLrfOYYmlVXaRLZTJDZvuXqpmTn9k342NT+fqsHHvT+qyLZ5V9iuma
QyjHiP8I4kfVS5nzZhTjkEnQHgxadsNEY1pnThDntAEFsZacajHBFDNi1UyzbHxr0EwCc5ALpdyY1F9CghdcJ2XEd8VjGFtLXn1oFQvJe
Ru5e5BfM7+rU8IN3iuyLHAgMBAAGjZDBiMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgP4MCAGA1UdJQEB/
eqW4mYYmDV+OE/BMszvjLl2wsIwDQYJKoZIhvcNAQELBQADggEBAHJL4re6ehAejTXBMGQAsIJ2Z4vdxeRb3N4qB1
EH3nUMxDmea5JCGO3b8=" ]
 }
}
Router#

Please note that the above output is a sample output which does not indicate actual values.

Collect Filesystem Inventory

The metadata of the filesystem can be collected using data dossier. The metadata of the file includes information about time the file was created, last accessed, last modified and so on. A snapshot is captured at each configured interval. The initial snapshot shows a complete snapshot of all files in the filesystem. The files are scanned periodically and new inventory data is collected and stored as incremental snapshots.

To enable this feature, use the filesystem-inventory command. 

Router(config)#filesystem-inventory 
Router(config-filesystem-inventory)#snapshot-interval 2
Router(config-filesystem-inventory)#commit

The snapshot-interval is the time interval in 15-minute blocks. The interval ranges 1–96. For example, value of 2 indicates that a snapshot interval is collected every 30 minutes. The snapshots are stored in./misc/scratch/filesysinv The logs are stored in /var/log/iosxr/filesysinv/*.

To retrieve the filesystem inventory, use the following dossier command. Output is presented in JSON format.

show platform security integrity dossier include filesystem-inventory | file <platform>-parent.json

{"collection-start-time":1610168028.380901,
"model-name":"http://cisco.com/ns/yang/Cisco-IOS-XR-ama",
"model-revision":"2019-08-05","license-udi":{"result-code": "Success", "license-udi": 
"UDI: PID:NCS-55A1-24H,SN:FOC2104R15R\n"},"version":{"result-code": "Success", 
"version": "Cisco IOS XR Software, Version 7.3.1
\nCopyright (c) 2013-2020 by Cisco Systems, Inc.\n\nBuild Information:\n 
Built By     : <user>\n Built On     : Thu Jan  7 17:16:02 PST 2021\n 
Built Host   : <host>\n Workspace    : <ws> 
Version      : 7.3.1\n  Location     : /opt/cisco/XR/packages/\n Label        : 7.3.1\n\ncisco 
() processor\nSystem uptime is 8 hours 7 minutes\n\n"},"platform":{"result-code": 
"Success", "platform": 
"Node              Type                       State             Config state
--------------------------------------------------------------------------------
0/RP0/CPU0        <node-type>(Active)       IOS XR RUN        NSHUT\n
0/RP0/NPU0        Slice                      UP                
0/RP0/NPU1        Slice                      UP                
0/FT0             <platform>-A1-FAN-RV       OPERATIONAL       NSHUT
0/FT1             <platform>-A1-FAN-RV       OPERATIONAL       NSHUT
0/FT2             <platform>-A1-FAN-RV       OPERATIONAL       NSHUT
PM1               <platform>-1100W-ACRV      OPERATIONAL       NSHUT
"},
----------------------------Output is snipped for brevity -------------------------------------
To limit the number of snapshots, use the following command:
show platform security integrity dossier include filesystem-inventory filesystem-inventory-options '{\"0/RP0/CPU0\": {\"block_start\": 0, \"count\": 1}}’ 

To start from a new block, use the following command:

show platform security integrity dossier include filesystem-inventory filesystem-inventory-options '{\"0/RP0/CPU0\": {\"block_start\": 5}}’ 
To collect data from a remote node, use the following command:
show platform security integrity dossier include filesystem-inventory filesystem-inventory-options '{\"0/RP1/CPU0\": {\"block_start\": 0}}’ | file harddisk:PE1_remote.json
Following is the sample of the display compact container:
{"node-data":[{"node-location":"node0_RP0_CPU0","up-time":150311,"start-time":"Tue Jul 27 13:55:12 2021","ima-event-log-compact":
["IlYIABoMCO+ggIgGEKmxwZYBIkQIABAKGhTU2yPVDA5Rx+64ecp41qZQrLEWSCACKhSXl+340O7Ta
xz5JUeBYFHIr05F7jIOYm9vdF9hZ2dyZWdhdGVAAQ=="]}]}

Incremental Integrity Measurement Architecture

With incremental Integrity Meansurement Architecture (IMA), you can define the starting IMA sequence that you want to include in a response. The system then starts to report the subsequent events.
show platform security integrity dossier incremental-ima 
"{\"ima_start\":[{\"0/RP0/CPU0\":{\"start_event\":1000,\"start_time\":\"Tue Feb 16 09:15:17 2021\"}}]}"

Associated Command(s)

  • show platform security integrity dossier

  • utility sign

Procedure to Test Key Generation and Data-signing with Different Key Algorithm

You can follow these steps to test key generation and data-signing with a different key algorithm:

  • Unconfigure the trustpoint (using the no crypto ca trustpoint system-trustpoint command)

  • Clear the certificates that were generated earlier (using the clear crypto ca certificates system-trustpoint command)

  • Generate new keys.

  • Configure the system trustpoint again.

  • Authenticate and enroll the system trustpoint to generate the certificates.

See How to Integrate Cisco IOS XR and Crosswork Trust Insights section for configuration steps of each task.

Verify Authenticity of RPM Packages Using Fingerprint

Table 4. Feature History Table

Feature Name

Release Information

Description

Verify Authenticity of RPM Packages Using Fingerprint

Release 7.3.1

This feature helps in verifying the authenticity of an installable package using fingerprint values. The fingerprint value of the package is compared with a point of reference called Known Good Value (KGV). The KGV for an image or package is generated after it is built by Cisco.

After installing the package, the associated install time and build time fingerprint values are compared using Yang RPC to determine whether the package is genuine. A match in the fingerprints indicates that the package published on CCO and that installed on router are the same.

Is there a simple way to determine the authenticity of a package that is installed on a router? Is there a mechanism to identify whether a package signature is checked at install time, or detect changes to the files after the package is installed at run time?

Cisco IOS XR, Release 7.3.1 introduces a fingerprint mechanism to verify the authenticity of a package that Cisco releases. This mechanism helps determine whether the installed package is genuine, where the installed and running software matches the software that is published by Cisco.

There are significant security measures for installing software using GPG and IMA signing. However, there is need to report more data for Cisco Crosswork application to monitor and flag potential issues for further investigation. Cisco Crosswork monitors the installed software over a period to help accomplish the following tasks:

  • To determine whether there are any differences between the software that is published on Cisco.com and that downloaded to the router.

  • To determine whether any files in a package have been altered, either accidentally or maliciously, from the time the package was installed.

A Known Good Value (KGV) is calculated and published for each package. This value is considered the right value for the package.

Two fingerprint (hex) values for each active or committed packages are monitored to ensure authenticity of the package:

  • Install time fingerprint: Hex value that represents the software in the package at install time. An RPM is genuine if it is not modified before install, and it matches the KGV. Whereas a manipulated RPM shows a mismatch in the fingerprint that is published in the KGV.

  • Run time fingerprint: Hex value that represents the running software of an installed package. The value matches the corresponding install time fingerprint if the RPM has not been modified since the install time. If there are changes to the files, the run time and install time fingerprints show a mismatch. Every time the files that are installed by an RPM are changed, the run time fingerprint also changes. A value of 0 (zero) is displayed if no run time fingerprint is available for a package. This is used to monitor changes to the running software over time.


Note

These two values are displayed only in the Yang model output. No CLI commands are provided to view these values.

 
Received message from host
<?xml version="1.0" ?>
<rpc-reply message-id="urn:uuid:97f5bc36-0eb0-4d2f-9c6f-3d34fea14be0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
    <install xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-spirit-install-instmgr-oper">
      <packages>
        <active>
         <summary>
          <rpm-fingerprint-status>generation-up-to-date</rpm-fingerprint-status>
            <rpm-fingerprint-timestamp>Mon Jun 15 15:58:22 2020</rpm-fingerprint-timestamp>
            <package>
             <name>asr9k-xr</name>
              <version>7.3.1</version>
              <release>r731</release>
             <gpg-key-id>ddcead3dcb38048d</gpg-key-id>
              <rpm-fingerprint>
              <rpm-fingerprint-install-time>2871bf68d3cd764938775afc9e5a69c130f9fbde</rpm-fingerprint-install-time>
              <rpm-fingerprint-run-time>2871bf68d3cd764938775afc9e5a69c130f9fbde</rpm-fingerprint-run-time>
              </rpm-fingerprint>
            </package>

           <package>
            <name>asr9k-mcast-x64</name>
            <version>2.0.0.0</version>
            <release>r731</release>
            <gpg-key-id>ddcead3dcb38048d</gpg-key-id>
             <rpm-fingerprint>
                <rpm-fingerprint-install-time>3ddca55bc00a0ce2c2e52277919d398621616b28</rpm-fingerprint-install-time>
                <rpm-fingerprint-run-time>3ddca55bc00a0ce2c2e52277919d398621616b28</rpm-fingerprint-run-time>
              </rpm-fingerprint>
            </package>
------------------------------ Truncated for brevity ---------------------------------

In the example, both the install time and run time fingerprints are the same.

The fingerprint generation status is used to indicate how up-to-date the run time fingerprints are. This may indicate that generation is currently in progress and will complete shortly, or generation is awaiting the end of an atomic change.

Support for Ed25519 Public-Key Signature System

Table 5. Feature History Table

Feature Name

Release Information

Feature Description

Support for Ed25519 Public-Key Signature System

Release 7.3.1

This feature allows you to generate and securely store crypto key pair for the Ed25519 public-key signature algorithm on Cisco IOS XR 64-bit platforms. This signature system provides fast signing, fast key generation, fool proof session keys, collision resilience, and small signatures. The feature also facilitates integration of Cisco IOS XR with Cisco Crosswork Trust Insights.

Commands introduced for this feature are:

crypto key generate ed25519

crypto key zeroize ed25519

show crypto key mypubkey ed25519

Commands modified for this feature are:

ca-keypair

keypair

The Cisco IOS XR Software Release 7.3.1 introduces the support for Ed25519 public-key signature algorithm on 64-bit platforms. Prior to this release, only DSA, ECDSA, and RSA signature algorithms were supported. The Ed25519 signature algorithm uses the elliptic curve cryptography that offers a better security with faster performance when compared to other signature algorithms.

You can generate the Ed25519 crypto keys either with an empty label or with two predefined labels: system-root-key and system-enroll-key . In case of empty label, the system generates the key pair against the default label. You can use the key pairs with the predefined labels to integrate Cisco IOS XR with Cisco Crosswork Trust Insights.

Generate Crypto Key for Ed25519 Signature Algorithm

Configuration Example

To generate the Ed25519 crypto key, use the crypto key generate ed25519 command in EXEC mode. 


Router#crypto key generate ed25519

To delete the Ed25519 crypto key with default label or any predefined label, use the crypto key zeroize ed25519 command in EXEC mode.

Verification

Use the show crypto key mypubkey ed25519 command to view all Ed25519 crypto keys generated on the system. 


Router# show crypto key mypubkey  ed25519

Mon Nov 30 07:05:06.532 UTC
Key label: the_default
Type : ED25519
Size : 256
Created : 07:03:17 UTC Mon Nov 30 2020
Data :
FF0ED4E7 71531B3D 9ED72C48 3F79EC59 9EFECCC3 46A129B2 FAAA12DD EE9D0351

Related Topics

Associated Commands

  • crypto key generate ed25519

  • crypto key zeroize ed25519

  • show crypto key mypubkey ed25519

Integrate Cisco IOS XR with Cisco Crosswork Trust Insights using Ed25519

Configuration Example

This section shows how to generate the system trustpoint, and the root and leaf certificates using the Ed25519 signature algorithm, as part of integrating Cisco IOS XR with Cisco Crosswork Trust Insights. 


Router#configure
Router(config)#domain name domain1
Router(config)#crypto ca trustpoint system-trustpoint
Router(config-trustp)#keypair ed25519 system-enroll-key
Router(config-trustp)#ca-keypair ed25519 system-root-key
Router(config-trustp)#commit

/* Generate root and leaf certificates */
Router#crypto ca authenticate system-trustpoint
Router#crypto ca enroll system-trustpoint

Running Configuration


config
domain name domain1
crypto ca trustpoint system-trustpoint
 keypair ed25519 system-enroll-key
 ca-keypair ed25519 system-root-key 
!

For the complete integration procedure, see, Integrating Cisco IOS XR and Crosswork Trust Insights.

Where to Go Next

After you have finished configuring CA interoperability, you should configure IKE, IPSec, and SSL. IPSec in the Implementing IPSec Network Security on the Cisco ASR 9000 Series Routermodule, and SSL in the Implementing Secure Socket Layer on the Cisco ASR 9000 Series Routermodule. These modules are located in System Security Configuration Guide for Cisco ASR 9000 Series Routers (this publication).

Additional References

The following sections provide references related to implementing certification authority interoperability.

Related Documents

Related Topic

Document Title

PKI commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Public Key Infrastructure Commands on the Cisco ASR 9000 Series Router module in System Security Command Reference for Cisco ASR 9000 Series Routers.

Standards

Standards

Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

MIBs

MIBs

MIBs Link
—

To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

RFCs

Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

 —

Technical Assistance

Description

Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport