Configuring, Verifying, & Troubleshooting IOS PKI

"The What?" - I want to walkthrough how to configure a Cisco IOS device to act as a certificate authority (CA), enroll a public key infrastructure (PKI) client (CSR) with the CA, & verify/troubleshoot configuration.


"The Why?" - So, from a super high level PKI authentication is all about who you trust, why we trust peers, how we go about trusting each other, and securing communications.

Some of the main PKI components consist of the following:

  • Peers communicating on a secure network

  • At least one certification authority (CA) that grants and maintains certificates

  • Digital certificates, which contain information such as the certificate validity period, peer identity information, encryptions keys that are used for secure communications, and the signature of the issuing CA

  • An optional registration authority (RA) to offload the CA by processing enrollment requests

  • A distribution mechanism (such as Lightweight Directory Access Protocol [LDAP] or HTTP) for certificate revocation lists (CRLs)

One of PKI main goals is to provide a scalable solution that includes a secure mechanism for distributing, managing, and revoking identity & encryption information. Clients (users or devices) that participate in PKI enroll with the CA/s for individual certificates that are then used to validate their identities, and secure communications.


Some PKI use case examples:

  • Securing emails

  • Securing web communications

  • Digitally signing software

  • Digitally signing applications

  • Encrypting files

  • Decrypting files

  • Smart card authentication

So to break this down further, public key cryptography AKA asymmetric encryption uses two keys, public & private. The two keys work together (keypair). The private key is used to encrypt, while the public key is used to decrypt. Note that when peers negotiate a secured communication session, digital certificates are exchanged. The public keys are now shared between peers, but note that the private keys remain secured locally to each respective client (not shared). A certificate is essentially a way of handing out that public key to users that the owner wants to have it. A high level flow looks like this: Server A and Server B initiate communication & exchange certificates. Then a file is encrypted on Server A via Server A private key, the data is sent encrypted to Server B, who then uses Server A public key to decrypt the data.


"The How?" - Cisco IOS PKI

Before we start I want to say that there are a lot of design decisions that should be considered, and PKI can be very complex. For the purpose of this post I intend on using two directly connected CSRs to walkthrough step by step configuring, & verifying/troubleshooting a basic PKI using Cisco IOS.


For our example, we will enroll our client via Simple Certificate Enrollment Protocol (SCEP; Trustpoint Authentication & enrollment over HTTP). The two CSRs in use are directly connected. Also, for understanding purposes - Trustpoint: is a containter to hold a certificate in IOS.


So let's cover some of the requirements, and configs so that we can focus on the task at hand here. Generic requirements include:

  • Authoritative time source (time is critical in PKI) - for this lab I manually configure time on the CSRs

  • A device hostname & domain-name

  • Both devices need a generated rsa keypair

  • Of course, have your underlay routing working between the nodes

  • Optional: configure domain name lookup (I did in the lab)

  • Mandatory Optional: enable logging :)

IOS Certificate Authority requirements:

  • Enable HTTP server

  • Configure & enable pki server

  • Verify local trustpoint is created after enabling pki server

IOS PKI Client requirements:

  • Configure trustpoint

  • Authenticate the trustpoint

  • Enroll for certificate

Ok so first thing first: Basic IOS CA configuration:

ip http server 
ip http port 8080
crypto pki server Cifelli-Lab
 database level names
 no database archive
 issuer-name CN=Cifelli-Lab,O=cifelli.lab.net
 grant auto
 hash sha512
 lifetime certificate 6000
 lifetime ca-certificate 7305

Configuration verification on IOS CA:

Next, we configure the IOS PKI Client:

IOS PKI Verification Commands:

Helpful IOS Client Verification:

# show crypto pki trustpoint <name>

# show crypto pki certificates <name>


IOS PKI Debugs:


Helpful IOS PKI Server/Client debugs to understand the transaction between Client and CA:

# debug crypto pki transactions


Helpful IOS CA Debugs:

# debug crypto pki server


First debug capture is from CSR3 (client) initiating the certificate request process:

Second capture is from CSR1 (PKI CA) showing SCEP request received which begins the process:

Third capture is from CSR1 stating that the certificate request has been granted & the process is completed:

Fourth capture is from CSR3 showing successful retrieval of identity certificate from CA:

Troubleshooting IOS PKI:

So I intentionally wanted to break a few things to debug errors.


So I intentionally deleted the crypto keypair that is used/referenced within the trustpoint config (# crypto key zeroize rsa). Note that this will remove any identity certificates that use the keypair.

Upon issuing certificate enrollment again (# crypto pki enroll <name>) the PKI client begins the process by auto-generating a new keypair to use. Note that since I left the rsakeypair name within the trustpoint config that the device names the keypair based on that. See below:

Once the device auto-generated the keypair the enrollment continued & worked as expected.


Next, I decided change the enrollment url in the trustpoint config purposely to reference the wrong port (# enrollment url http://192.168.4.1:80) instead of 8080 like how I manually setup the server port on the IOS CA earlier. You can see we have expected connection issues & unsuccessful enrollment:

I also purposely disabled the PKI Server on the IOS CA and tailed debugs to troubleshoot enrollment issues from my IOS PKI Client. As you can see in the HTTP reply header from the CA the server is disabled, then closes the connection, and our Client is unsuccessful with obtaining an identity certificate:

Lastly, I decided to manually revoke the PKI Client certificate just to understand how the PKI Server would operate within IOS. By default all issued identity certs are stored in nvram (not best practice). I proceeded with revoking the last issued cert, and the PKI server immediately updates the CRL. To verify I was revoking the correct cert I looked at nvram and the last issued cert via the serial number in hex. Remember earlier I changed the database level to names.

After revocation the device immediately updates the CRL.


We have now configured a basic IOS PKI CA & an IOS PKI Client who successfully auto-enrolled for an identity certificate via SCEP. We also walked through verification steps, and a few troubleshooting scenarios. In later posts, we will dive much deeper into more complex scenarios to include using the IOS PKI certificates for VPN authentication. Cheers!


0 comments

Recent Posts

See All

Configuring & Verifying FlexVPN Hub & Spoke Tunnels

"The What?" - In this post we will go over setting up FlexVPN hub & spoke tunnels. We will utilize SVTIs on our spokes, DVTIs derived from virtual templates on our hub, IOS PKI certificate authentica

#learnITwithCifelli

© 2023 by Train of Thoughts. Proudly created with Wix.com