PKI for Network Engineers (2.5/?): Web Server basic Setup

Greetings!

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.

 

 

Happy labbing!

 

-s

PKI for Network Engineers (3/?): RSA Offline Root

Greetings Professor Falken,

giphy

How about Global Thermonuclear War  setting up a two level CA hierarchy?  This is great configuration for labbing and for medium to largish enterprises.  As I discussed at the end of part one of this series, you would never want to deploy an enterprise root in a real network.  So why not model best practices in our lab?

Ok, let’s get started.

NOTE:  Before we configure anything, it’s important to do some planning and sort out all the naming conventions.  If you want to follow along with the videos, check out the attached: Setup Text Block File and a Diagram  which you can edit to customize for your lab.  I also included links to some resources in the doc.  I found Timothy Gruber’s guide on setting up Windows 2016 PKI enormously helpful.

There’s a lot of work to be done, so I’ll break it up into 15-20 minute chunks.

In this video we set up the offline root.

 

 

 

IKEv1/v2/IOS/ASA Cheatsheet

Greetings fellow networkers.

This is a cheat sheet to cross reference the differences between the two versions of IKE as implemented on Cisco IOS and ASA.

I used Crypto Maps with pre-shared authentication as the reference example because  Virtual Tunnel Interfaces are fairly new on the ASA and I wanted a broadly applicable baseline.  To apply these to tunnel interfaces is a simple matter of replacing the crypto map with an IPSEC profile and calling that under your tunnel interface.

IKEv2 is not cast in the best light here based on the additional configuration in the example, but understand it has an enormous amount of flexibility and maintains a consistent configuration syntax and workflow for all of the VPN permutations compared to IKEv1, where things were bolted on over time.  Additionally, you need IKEv2 to utilize next generation crypto suites.  There’s really no reason to use IKEv1 in new deployments.

Best wishes,

-s