Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn how to implement Public Key Infrastructure (PKI) on IOS Routers and ASA with Naman Latif. Naman is a customer support engineer at Cisco’s Technical Assistance Center for VPN and security technologies. He has been with Cisco for more than two years and currently is a Technical Lead for his group. His area of expertise includes configuration and troubleshooting for Cisco’s security product portfolio including VPN, PKI and firewall technologies. He holds a bachelor’s degree in electrical engineering from the University of Engineering & Technology, Lahore in Pakistan. He also holds CCIE certification (# 15951) in Security.
Remember to use the rating system to let Naman know if you have received an adequate response.
Naman might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through November 19, 2010. Visit this forum often to view responses to your questions and the questions of other community members.
1.I would like to know if the asa can act as certificate authority and sign certificates from other routers/asas
2. there is an option to generate a self-signed certificate and act as a local certificate authority. is this used only for ssl?
1. ASA can act as a Local CA Server but this functionality is only commonly used\supported for SSL\AnyConnect Users.
Below link can provide you more information on this
2. When configuring ASA as a Local CA\CA Authority , then it will generate a Self-Signed Certificate , which will be used as the CA certificate.
You can then provide the Remote Users OTP (One-Time Password) , which they can use to access the ASA and get an End-User Certificate. This certificate can then be used to establish Clientless\AnyConnect sessions.
I have also attached a PDF that explains the process in more detail with Snapshots.
Hope this helps.
Can you point me to current documentation that details current best practices and configuration when using Microsoft PKI and SCEP to enroll and subsequently auto renew certificates issued to remote routers?
Below are some examples for IOS certificate enrollment using a Microsoft CA with SCEP.
The above links also discuss the Auto-Enrollment feature. The value\threshold chosen for Auto-enrollment is dependent on your setup but 75% is a reasonable value that we have seen being used.
You will also need to make sure that your Windows CA is set to Grant "Auto" (Instead of Manual) , if using Auto-Enrollment.
Let me know, if you have any follow-up questions.
I've been trying to get my head around rollover with regards to PKI.
I've been bitten in the past with setting up a lovely DMVPN network using PKI, then 2 years after implementing this, everything fails as the cert expired!
From what I can gather on the root CA should have auto-rollover enabled eg:
crypto pki server CA
on the trustpoints the regenerate command should be used -
crypto pkie trustpoint root_ca
Is this all that is needed to enable roll over? Testing this is something that I plan to implement, but haven't got round to it yet :-)
Can you see any cotchas with it?
There are a few requirements that need to be satisfied for your PKI infrastructure to keep working when certificates expires (either CA or Client Certificates)
Since you are thinking of auto-rollover for the CA certificate so I am assuming that you will be using IOS CA. Below link is a detailed guide on implementing an IOS CA
Within the above document, you can find some details on the requirements for enabling Auto RollOver in your network in the section "Prerequisites for Automatic CA Certificate Rollover".
As for basic configuration you will have
1. "auto-rollover" configured under the "crypto pki server X" section on the IOS CA Server.
2. "auto-enroll" configured under the "crypto pki trustpoint X" section on the Client Routers.
3. "regenerate" command is optional and depends on your security policy, if you want to use a new KeyPair for the new certificate etc.
4. The clients should be using SCEP for Enrollment.
If you have the ability to test a particular Code version in Lab before deployment then all you needs is 2 Routers acting as CA Server and Client. Configure the CA lifetime to maybe 1 day and the Client Certificate lifetime to maybe 16 hours etc. You can then monitor the setup and verify that everything is still working after Certificates expire for Client\CA etc.
Some debug to help are
debug crypto pki messages
debug crypto pki transactions
debug crypto pki server
Hope this helps.
Thank you very much for taking the time to reply. I really appreciate it mate.
I missed the auto-enroll command, I see that there's an "auto-enroll regenerate", where the keys are re-generated in re-enrollment. From a security perspective I presume that this would be best practice?
Many thanks again
I am glad the content was helpful.
Yes, I would agree that from a security perspective you can 'regenerate" the keys. Even though the Private Key is never stored in Config\Flash but still it doesn't hurt to try to make it more secure..!
With regards to SCEP, this runs over http which is insecure. I know it be possible for an attacker to perform a man-in-the-middle attack with regards to a SCEP enrollment, but if an attacker were to just capture the SCEP enrollment, would this benefit the attacker in any way? I can't see any way that someone could perform any reverse engineering from viewing the SCEP process??
I've managed to register IOS devices over https in a lab by enabling "ip http secure-server" on the CA and "enrollment url https://" on the trustpoint, but haven't found this documented on CCO - is this a recommended solution?
Many thanks again for sharing your expert knowledge!
Before sending a SCEP request the router generates a Private\Public Keypair. The request sent to the CA server only contains the Public Key of the Router and private keys are never sent.
The Public key of any peer is 'public' knowledge anyways, so I don't see much concern in running this over http.
However as always you can also contact your Cisco Account Team and they can look at your network design\setup and can make recommendations etc.