Greetings fellow networkers,
In this installment of PKI for network engineers, we’re going to build up our two tier Elliptic Curve PKI hierarchy in one shot. There are a lot of tasks, but only a few of them differ from our RSA setup. I’ll highlight those below.
- Cryptographic service provider and Hash algorithm.
- I’m using ECDSA 384 and SHA384
- Although the Microsoft CA supports 521 bit EC Keys, Cisco IOS maxes at 384
- No NDES/SCEP. NDES supports RSA only for in-band device enrollment
- There is a new standard called EST (enrollment over secure transport)
- IOS and IOS-XE support EST as clients
- There’s an open source project called libEST you can use to test.
- Cisco ISE as of version 2.2 supports EST
- Web enrollment doesn’t support version 3 or 4 templates
- When duplicating templates, be aware of this fact
- Mind your signatures and public key algorithms.
- RSA public keys can be signed by a EC CA and vice versa. Keep this in mind when creating your templates and take care to test them and inspect your certificates to make sure you’re getting what you think you’re getting
Settings, scriptlets, helpful text blocks:
In this installment of the series, we set up the Active directory plumbing needed to do Certificate Autoenrollment for users and computers, and then we test it. In the vein of the series, rather than taking defaults which are often not the best idea in a production network, we build things up in a more realistic manner.
In addition to learning how to set up auto enrollment, if you follow along, you’ll get some practice in doing some basic windows sysadmin including creating users, groups and organizational units, creating group policy objects, and most importantly working with certificate templates.
As usual, I included some links of interest at the bottom.
configuring Certificate Autoenrollment: https://technet.microsoft.com/en-us/library/cc731522(v=ws.11).aspx
Troubleshooting Certificate Autoenrollment: https://social.technet.microsoft.com/wiki/contents/articles/3048.troubleshooting-certificate-autoenrollment-in-active-directory-certificate-services-ad-cs.aspx
Greetings fellow Networkers!
In today’s installment, we’re going to configure network Device Enrollment Service, Microsoft’s implementation of SCEP. Then we’ll enroll a router in-band.
A couple of things to note:
- By Default, NDES requires a one time password for enrollment. This can be disabled via registry key.
- SCEP does not work with Elliptic Curve Certificate Authorities. Enrollment over Secure Transport Supports in-band EC enrollment and is considered the successor to SCEP.
- I attached a pcap of all SCEP activity between the router and the CA. if you look at the Cisco doc, it’ll explain what’s happening so you can interpret the activity in the PCAP.
PCAP of SCEP activity in video: https://www.cloudshark.org/captures/62d72e489181
SCEP RFC: https://www.ietf.org/id/draft-gutmann-scep-06.txt
Cisco TechNote on SCEP (very well written): https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html
Microsoft Guidance on installing and configuring NDES: https://technet.microsoft.com/en-us/library/hh831498(v=ws.11).aspx
Finally! After all the work we’ve done, we get down to the business of actually issuing a certificate to a router. We set up the web enrollment service, configure a template, and enroll a router.
At the very end I also point out a few things about the issued certificate. With all the work we’ve done to this point, it’s cool to see it all being put to use. I didn’t go in to a lot of detail because I wanted to keep it short, but I think it’s really worthwhile to study the certificates you issue from your lab pki and learn what the different fields are and what they are used for, and how they relate to the configuration of your pki.
Here are snippets of the different commands I used on the router in the video.
In the next installment we’ll look at network device Enrollment service, which is Microsoft’s implementation of SCEP.
Thanks for watching and I hope you find this helpful.
In this installment of PKI for network engineers, we’re going to install an online responder. the Online responder implements a lightweight version of OCSP or Online Certificate Status Protocol. it’s an HTTP based method for entities to check the whether a certificate has been revoked or not. This is an alternative to the Certificate Revocation List (CRL) which is a file that contains a list of all revoked certificates, and can grow quite large over time.
In addition to demonstrating the setup and configuration of the Online Responder, I also demonstrate a handy PKI verification utility called pkiview.
Using pkiview, I review and discuss a couple of mistakes I made in the AIA extensions of My CAs.
If you would like to know more about the Microsoft Online Responder and pkiview, Click the links at the bottom of this post.
Thanks for stopping by, and I look forward to posting the next installment of our awesome lab PKI build.
Online Responder installation and troubleshooting guide.
Quick Check on ADCS Health Using Enterprise PKI Tool (PKIVIEW)
Greetings Fellow Geeks!
In this post, we’re going to set up our enterprise issuing CA for RSA based certificates.
The workflow is pretty straightforward. The steps are:
- publish root Cert to AD
- add root cert and crl to local store
- install services
- configure CDP and AIA extensions
- run scripts
- copy enterprise cert to web server and rename
- publish CRL and Delta CRL
Here are text snippets to help out if you would like to follow long and build your own issuing CA while watching the video:
The video came out a little bit long due to some troubleshooting at the end, but I think it showed a couple of helpful things about checking the details of your certificates and fixing mistakes. Let me know if you think this is too long and I’ll make a shorter version.
In this post we’re going to take a quick walk-though of the the web server that will host our Root certs, CRLs (certificate revocation lists) and act as the Online Responder for our CAs. This server is referenced in the AIA and CDP fields of the certificates we issue, so clients will check with this server as part of the certificate validation process.
Because this is the place clients always come to check certificate validity, high availability is important. In a production install this would be two or more servers ideally sitting behind a load balancer with a virtual ip address.