Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
6350
Views
5
Helpful
1
Comments

Building an IOS XE Offline Root and Subordinate Certificate Authority

Tim Glen
Cisco Employee
Cisco Employee

‎02-07-2022 04:38 AM - edited ‎02-08-2022 10:43 AM

 

Table of Contents

 

 

Summary

A Certificate Authority is a device that issues digital certificates. Certificate Authorities are required in modern-day networks to facilitate trust between endpoints. Endpoint devices with certificates can be trusted to be who they say they are. In a conversation with two endpoints, the endpoints should trust the Certificate Authority, and as such, the CA acts as a trusted third party. When both the endpoints trust the CA, they gain a high level of confidence that they can trust other endpoints that have a certificate from the CA that they themselves trust.

 

 

 

certificate-trust.png

 

 

 

Certificates and Public Key Infrastructure (PKI) use a public and a private key. Certificates are necessary in today's networks for a multitude of reasons, some of the most popular are verifying website identity and providing keying material that enables HTTPS.

 

Terminology

Please see this other document I authored for terminology and file type information.

 

Requirements

Two IOS XE routers. 

One router will be used for the Root CA, and the other router will be the Subordinate CA.

In this lab, I'm using two CSRv IOS XE Routers. Each router runs IOS XE 17.3(4).

 

 

Configuration Steps

This document is meant to be a prescriptive guide to build a Root and Subordinate CA.  

This guide is *not* meant to be an exhaustive document on Certificate Authorities, Certificate usage or Certificates.

 

 

Configure DNS

Decide on FQDNs. DNS records are not required for Certificate Authorities but they do make implementation and usage easier, I always use them whenever I can. For this configuration, we will need to configure two FQDN, one for the Root CA and one for the Subordinate CA.

 

 

Build \ Configure the Root CA

First, we will configure the Root CA. The Root CA will only issue certificates to Subordinate Certificate Authorities, it should not be used to issue certificates to endpoints.

This CA will use a 2048 bit RSA key pair and a SHA-384 Signature Algorithm. Best practices state that CA's should use a 2048 bit key!   On the Root CA, Certificate Requests will need to be approved by the Certificate Authority Administrator, this is because this Root CA will likely only issue a few certificates to Subordinate CAs and we don't want endpoints asking the Root for certificates.

 

 

Enable NTP on the Root CA

Valid time is critical on a Certificate Authority. I prefer to use pool.ntp.org, so that's what we will do here. Because pool.ntp.org are all FQDN based, we will need the IOS XE box to resolve names. If reliable time is not available on the IOS XE device you may see this error.

% Time has not been set. Cannot start the Certificate server.

1.1.1.1 is a publicly available Cloudflare DNS service.

8.8.8.8 is a publicly available Google DNS service.

!
configure terminal
ip name-server 1.1.1.1 8.8.8.8 
ntp server us.pool.ntp.org
ntp server south-america.pool.ntp.org
ntp server north-america.pool.ntp.org
ntp server europe.pool.ntp.org
ntp server pool.ntp.org
end
!

 

Generate the RSA Key Pair on the Root CA

Here we will manually create RSA Keys. The label MUST match the CA Server Name.

When generating keys the default modulus is 1024 bits, however best practices state the recommended modulus for a certificate server RSA key pair is 2048 bits, so we need to create the keys manually. We are also going to use exportable keys, so we can back them up.

 

NOTE: In this document, we name our Certificate Authority, YOUR-ROOT-CA-NAME. In your network please use a name that is relevant to your organization. 

!
crypto key generate rsa general-keys exportable label YOUR-ROOT-CA-NAME mod 2048 
!

 

 

Backup the Keys on the Root CA

Once you backup the keys you should move them offline to a secure location. The backup of these keys should allow us to move our Root CA to another IOS XE box if we ever needed to.

!
mkdir CAKEYS-BACKUP
crypto key export rsa YOUR-ROOT-CA-NAME pem url bootflash:CAKEYS-BACKUP/ aes MAKE-A-PASSWORD-HERE
!

 

 

Enable the IOS XE HTTP Server on the Root CA

IOS XE can support an HTTP server for multiple purposes. Because this router will only be used as a Certificate Authority we will configure the HTTP server to only accept SCEP requests.

!
configure terminal
  ip http server
  no ip http secure-server
  no ip http authentication 
  ip http session-module-list http-module-list SCEP
  ip http active-session-modules http-module-list
end
!

 

 

Create the Root Certificate Authority Server.

The Root CA will use the 2048 bit RSA key pair we created earlier. 

The Root CA's certificate will have a ten-year validity life.

The Root CA will issue certificates to Subordinate CA's with a three-year lifetime.

A rollover certificate will be created on the Root CA 365 days before the Root CAs certificate expires. Rollover enables the CA to generate a new certificate before its own expires. Please see the References section of this document for deep dive into Rollover \ Shadow Certificates and timer usage.

Database level complete will save the entire certificate into the database URL.

 

 

NOTE: Please use Issuer Name information that is relevant to your organization. 

!
mkdir bootflash:/pki-cert
configure terminal
  crypto pki server YOUR-ROOT-CA-NAME
  hash sha384
  database level complete
  database archive pkcs12 password MAKE-A-PASSWORD-HERE
  issuer-name cn=YOUR-ROOT-CA-NAME, c=Your2DigitCountryCode, ST=YourState, L=YourTown, O=YourOrganization, OU=YourSubOrganization
  grant auto rollover ca-cert
  lifetime ca-certificate 3652
  lifetime certificate 1095
  auto-rollover 365  
  database url bootflash:/pki-cert/
  no shutdown
end
!

 

Look for the phrase to know the process completed successfully.

% Certificate Server enabled.

 

 

Validate the Root CA

We want to see that the CA server is enabled.

show crypto pki server

root-show-crypto-pki-server-WEB.png

 

 

 

show crypto pki certificates verbose YOUR-ROOT-CA-NAME

root-show-crypto-pki-cert-verb-WEB.png

 

 

 

show ip http server session-module

root-show-ip-http-WEB.png

 

 

 

The configuration on the Root CA is complete.   It's now time to move on and configure the other router.

 

 

Build \ Configure the Subordinate CA

Next, we will create the RSA Based Subordinate Certificate Authority in these next steps. This is the CA that will issue certificates to all the SCEP clients.

 

  • The Root Certificate Authority must be a Cisco IOS XE certificate server.
  • Manual enrollment of Subordinate CA to the Root CA or upstream CA is not supported.
  • For a subordinate certificate authority (CA), enrollment to the Root CA or upstream CA is possible only through SCEP.

 

 

Enable NTP on the Subordinate CA

Valid time is critical on a Certificate Authority. I prefer to use pool.ntp.org so that's what we will do here. Because pool.ntp.org are FQDN based we will need the IOS XE box to resolve names.

1.1.1.1 is a publicly available Cloudflare DNS service.

8.8.8.8 is a publically available Google DNS service.

!
configure terminal
ip name-server 1.1.1.1 8.8.8.8 
ntp server us.pool.ntp.org
ntp server south-america.pool.ntp.org
ntp server north-america.pool.ntp.org
ntp server europe.pool.ntp.org
ntp server pool.ntp.org
end
!

 

 

Generate the RSA Key Pair on the Subordinate CA

Here we will manually create RSA Keys. The label MUST match the CA Server Name.

When generating keys the default modulus is 1024 bits, however best practices state the recommended modulus for a certificate server RSA key pair is 2048 bits, so we need to create the keys manually. We are also going to use exportable keys, so we can back them up.

 

NOTE: In this document, we name our Certificate Authority, YOUR-SUB-CA-NAME. In your network please use a name that is relevant to your organization. 

!
crypto key generate rsa general-keys exportable label YOUR-SUB-CA-NAME modulus 2048
!

 

 

Backup the Keys on the Subordinate CA

Once you backup the keys, you should move them offline to a secure location. The backup of these keys should allow us to move our Subordinate CA to another IOS XE box if we ever need to.

!
mkdir CAKEYS-BACKUP
crypto key export rsa YOUR-SUB-CA-NAME pem url bootflash:CAKEYS-BACKUP/ aes MAKE-A-PASSWORD-HERE
!

 

 

Configure the Subordinate CA Trustpoint

This trustpoint will hold two certificates; the Root CA certificate and the Identity Certificate that the Root hands out to this Subordinate CA.

 

NOTE: Please use Issuer Name information that is relevant to your organization. 

!
configure terminal
crypto pki trustpoint YOUR-SUB-CA-NAME
  enrollment url http://YOUR-ROOT-CA-FQDN  ! this was defined in earlier steps
  hash sha256 
  subject-name cn=YOUR-SUB-CA-NAME, c=Your2DigitCountryCode, ST=YourState, L=YourTown, O=YourOrganization, OU=YourSubOrganization
  fqdn YOUR-SUB-CA-FQDN.COM
!
end
!

 

 

Create the Subordinate Certificate Authority Server

The subordinate server must have the same name as the trustpoint above.

At the end of this configuration block, be ready to accept the fingerprint from the Root CA and enter to enter a challenge password.

!
mkdir pki-cert
configure terminal
crypto pki server YOUR-SUB-CA-NAME
  database url bootflash:/pki-cert/
  database level complete
  database archive pkcs12 password MAKE-A-PASSWORD-HERE
  issuer-name cn=YOUR-SUB-CA-NAME, c=Your2DigitCountryCode, ST=YourState, L=YourTown, O=YourOrganization, OU=YourSubOrganization  
  lifetime certificate 365
  mode sub-cs 
  eku client-auth server-auth
  auto-rollover 241
  hash sha256
  grant auto rollover ca-cert
  grant auto 
  no shutdown
!

 

See the screenshot below.

You will need to accept the fingerprint from the Root CA.

You will also need to type in a password before continuing.

sub-crypto-pki-server-creation-WEB.png

 

 

 

Before we grant the request on the Root CA, let's quickly look at the Sub CA status.

!
show crypto pki server
!

sub-show-crypto-pki-server-init-WEB.png

 

Now that we see the Subordinate CA status is pending let's move on to granting the certificate request.

 

 

Grant the Identity Certificate to the Subordinate CA

Now we have to login back into the Root CA.  

Recall that when we set up the Root CA, we configured it to require manual approval before issuing certificates. So here we will manually grant that certificate request.

 

Here we will look for certificate requests on the Root CA.

!
show crypto pki server YOUR-ROOT-CA-NAME requests
!

root-crypto-pki-server-grant-WEB.png

 

 

Now that we see the Request ID, we can grant it, in this case the request is ID #1.

!
crypto pki server YOUR-ROOT-CA-NAME grant 1
!

 

It will take a few minutes for the SubCA to 'check-in' with the RootCA and obtain its new certificate. 

 

Validate the Subordinate CA

Now we will validate the Root CA has issued a certificate to the Subordinate CA. Please issue this command on the Root CA.

!
show crypto pki server YOUR-ROOT-CA-NAME certificates
!

root-show-crypto-pki-server-certificates-WEB.png

 

 

 

Now let's validate that the Subordinate CA is running.

!
show crypto pki server YOUR-SUB-CA-NAME
!

sub-show-crypto-pki-server-WEB.png

 

 

 

Congratulations!     You now have a working Root & Subordinate Certificate Authority. 

 

You should now be able to configure certificate enrollment on IOS XE devices. 

Shortly I will link a document here that explains how to do that.

 

 

 

Revoking Certificates

 

 

Troubleshooting

debug crypto pki server

debug crypto pki scep

debug crypto pki transactions

debug crypto pki messages

 

 

 

If you have made it this far please click Helpful.  

 

References

RFC 5280 - Internet x.509 PKI Certificate

Public Key Infrastructure Configuration Guide, Cisco IOS XE 17 

IOS PKI Auto-Enroll, Auto-Rollover, and Timers 

IOS PKI Deployment Guide Certificate Rollover Config & Operation Overview

Simple Certificate Enrollment Protocol Overview

Cisco IOS Security Command Reference: Commands A to C

Cisco IOS Security Command Reference: Commands D to L

Cisco IOS Security Command Reference: Commands M to R

Cisco IOS Security Command Reference: Commands S to Z

 

Wikipedia: Certificate Authority

 

 

 

 

Comments
Elito Haylett
Level 1
Level 1
‎10-10-2023 05:19 PM

 I was reading your post " Building an IOS XE Offline Root and Subordinate Certificate Authority" and have a few questions. This post is one of the most laymens explanation of configuring CA on Cisco IOS XE that I have come across in months of trying to configure AnyConnect and IKEv2 or Flex VPN on IOS XE. I'm no where even close to having the same technical abilities I used to have so a lot of these topics are a little over my head. I have an open post on this forum regarding the issues I ran into with my configuration which haven't been answered so in my continous and exhaustive searching for answers I ran across your post so i said what the hec let me try reaching out to you directly to see if maybe you can provide a little bit of insight. It appears my issue is with Certificates because the message I'm getting from the client trying to authenticate is this:Screenshot 2023-10-10 124050.pngYour post gave me a better understanding of creating the certificates but the only difference is I have one IOS XE router, no sub CA that need to issue the certificates to VPN clients. I'm posting my CA configs and a couple of the show commands. I don't really know if this is correct and will work because I was just borrowing from some of the configs I ran across on this forum and others.

Key name: ECH-VPN-CA
Key type: RSA KEYS
Storage Device: not specified
Usage: General Purpose Key
Key is exportable. Redundancy enabled.

crypto pki server ECH-VPN-CA
issuer-name CN=ECH-ISR4431-138.dyndns.org,OU=IT,O=ECH Communications
no database archive
grant auto
hash sha512
eku server-auth client-auth
database url flash:ech-ca

crypto pki trustpoint ECH-VPN-CertAuth
enrollment url http:http://ECH-ISR4431-138.dyndns.org:80
subject-name CN=ECH-ISR4431-138.dyndns.org,OU=IT,O=ECH Communications
subject-alt-name ECH-ISR4431-138.dyndns.org
revocation-check none
rsakeypair ECH-VPN-CA
hash sha512
eku request server-auth client-auth

ECH-ISR4431-138#show crypto PkI certificates
Certificate
Status: Available
Certificate Serial Number (hex): 02
Certificate Usage: General Purpose
Issuer:
cn=ECH-ISR4431-138.dyndns.org
ou=IT
o=ECH Communications
Subject:
Name: ECH-ISR4431-138.dyndns.org
hostname=ECH-ISR4431-138.dyndns.org
cn=ECH-ISR4431-138.dyndns.org
ou=IT
o=ECH Communications
Validity Date:
start date: 11:29:38 est Oct 10 2023
end date: 11:29:38 est Oct 9 2024
Associated Trustpoints: ECH-VPN-CertAuth

CA Certificate
Status: Available
Certificate Serial Number (hex): 01
Certificate Usage: Signature
Issuer:
cn=ECH-ISR4431-138.dyndns.org
ou=IT
o=ECH Communications
Subject:
cn=ECH-ISR4431-138.dyndns.org
ou=IT
o=ECH Communications
Validity Date:
start date: 11:06:18 est Oct 10 2023
end date: 11:06:18 est Oct 9 2026
Associated Trustpoints: ECH-VPN-CertAuth ECH-VPN-CA

Any help in looking over my CA configuration will be greatly appreciated. 

Thank you very much for your time..

Regards,

Elito

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents