PKI for Network Engineers (4/?): RSA Enterprise CA setup

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:

  1. publish root Cert to AD
  2. add root cert and crl to local store
  3. install services
  4. configure CDP and AIA extensions
  5. run scripts
  6. copy enterprise cert to web server and rename
  7. 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.


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


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!



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

Greetings Professor Falken,


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,


PKI for Network Engineers (2/4): Directory Services

Greetings dear readers,

In this blog post, we’re going to build the active directory infrastructure needed to build out our PKI.  In part 1, we went over some theory and background information. It’s not necessary to read that post to continue on, however since understanding the fundamentals of how PKI works is an objective of the series, I recommend it.

If you’re already familiar with active directory administration you can check out the lab info for the build and set it up.  For everyone else I’ve stepped through setting up our domain controller and joining a workstation to the domain.

This was supposed to be a three part series, but the AD setup resulted in a fairly sizable post on it’s own.  So this now a four part series. 🙂

Table of contents:

  • Lab Hardware
  • Lab Topology
  • Active Directory Domain Services
  • DHCP
  • Join workstation to domain

Lab Hardware, operating systems used:

This lab is being run on an Intel NUC running VMWare ESXi 6. It has 32gb of ram and a 500gb m.2 SSD

2016-07-31 16.30.40.jpg

These little guys are great.  They’re silent, fast, portable, and use very little power.  If you want to build one for yourself, here’s the parts list on Amazon:

As of this writing, the build cost is approx. $635.00

ESXi is a free download from  If you want to run vcenter (which is very nice to have), you can either download the evaluation version, or join VMUG Advantage.  VMUG Advantage is $200.00 a year and you get a pretty impressive list of toys to play with for the money. If you’re labbing at home a lot and want to run more than one ESXi host, I think it’s a good deal.  That can be found at

The windows VMs were spun up using Windows 2012r2 for the servers and Windows 10 Enterprise for the management station.  You can download evaluation versions of these images from

Lab Topology:


Lab topology

Here’s the list of the machines, and what functions they’re going to serve:

  • dc01: active directory domain controller, DNS, DHCP
  • pki01: standalone root CA.  Not domain joined
  • pki02: enterprise issuing CA.  website for hosting CDP and AIA.  Network device enrollment service.
  • nps01: network policy server.  This will function as a radius server.
  • pc01: management station.

The domain should have two OUs created:

  • Densemode users
  • Densemode computers

In the densemode users ou, create an account called user1 with a password of Pass123.

The administrator password on all machines will be Pass123.

The steps to set everything up follow, so don’t worry if you’re sure what do to.

Setting up Active Directory Domain Services (ADDS)

Prior to setting up ADDS, please ensure the dc01 machine has the following settings applied:

  • Computer Name: dc01
  • IP address:
  • Network mask:
  • Default gateway:
  • DNS Server

These items can be verified and configured from the local server pane of Server  Manager:



Once that’s done, we’re ready to configure ADDS and DHCP.

With the local server selected, click manage, Add roles and features.


Click Server Selection:


Click Server Roles, select Active Directory Domain Services:


Make sure ‘include management tools’  is selected, and click add features:


Click Confirmation, then Install :


When the ADDS role has been installed, the screen will look like this:


Note the text under the installation progress bar.  Click Close.

Server Manager will now have a Yellow Triangle in the notification area.  Click on the flag and click ‘promote this serve to a domain controller’


At the deployment configuration screen, select ‘add a new forest’, and type in a root domain name.  Then click next:


At the Domain Controller Options scree, enter a Directory Services Restore Mode (DSRM) password.  My suggestion for labbing purposes is to use Pass123.  Then click Next:


You’ll see a warning on the DNS options screen that can be safely ignored. Click Next:


Accept the NetBIOS domain name, and click Next:


On the Paths screen click next:


On the review options screen, click Next:


On the Prerequisites check screen, you’ll see some yellow triangles.  They’re informational in nature.  Go ahead and click install:


Once the installation is complete the machine will reboot.  This is normal. Go ahead and log back in once windows has restarted. Server manager should launch automatically.  If it doesn’t go ahead and launch it by clicking on it’s pinned icon on the task bar.

Let’s verify that our domain controller is functioning correctly.

From Server Manager click Tools, Active Directory Users and Computers (ADUC):

Right click on the domain object, click New, Organizational Unit.


Type in densemode users.  if you used a different domain name, go ahead and substitute densemode with the name you used.  Then click Ok:


Click on the right facing triangle to the left of the domain object to expand the list of containers.  You should see the OU you created. Right click on it, and click new, user:


Fill in the first name, last name, and user logon name, then click next:


Use Pass123 as the password.  Uncheck ‘user must change password at next logon’, check ‘password next expires’.  NOTE:  You would never want to disable password expiration on a live network.  This is for labbing purposes only:


Click Finish:


PRACTICE:  Create an OU in your domain called ‘densemode computers’.  If you used a different domain name, use the one you created.  Then right click on the domain node and click refresh.  When you are done, you should have  <domain> users and <domain> computers OUs next to each other like this:


As we move through later tasks, we’ll be making use of these containers.  This is a good time to point out that in Active Directory it’s always a good idea to use your own OUs for user and computer objects rather than the default users and computers OUs.  The reasons for this will become clearer later on when we get to using group policy objects.

Additionally, by creating these objects, we’ve verified that our domain controller is working.

Setting up DHCP

Another infrastructure service we’re going to want in our test environment is DHCP.  This will make it easy to add additional client devices.  It’s pretty easy to set up, just make sure not to run it on your actual home network.  Ideally you should run it on an isolated network.  In my lab, I’m a using vswitch that’s not backed by physical nic:


Let’s get started.

In Server Manager on dc01, click Manage, Add roles and Features


Click Server Selection:


Now click Server Roles, DHCP Server:


Select add features:


Select Confirmation, Restart the destination server if required, and click yes:

Click Install:


When installation is complete you will see the Configuration required/Installation Succeeded message. Click Close:


Click the notification flag, then select Complete DHCP configuration:


Click Next:


Click commit to authorize the DHCP server service in AD:


Click Close:


Setting up the DHCP Scope

In server manager select tools, DHCP:


In DHCP manager expand the server node, right click on ipv4, and select New Scope:


Click next to begin the New Scope Wizard:


For the name enter “subnet 1”, then click next:


On the ip address range screen, enter a range of to, with a subnet mask of  Click next:


On the exclusions and delay screen, click next:


Change the lease duration to 8 hours.  Click next:


Select “yes I want to configure these options now”.  Click next:


For the router, enter, click add. Then click Next:


The DNS screen should pre-populated with the DNS suffix and DNS server.  The DNS server should be  Verify the settings and click next:


Leave WINS servers blank.  Click Next:


Select “yes I want to activate this scope now”.  Click Next:


Click Finish:


Verify DHCP and join workstation to the domain

Now we’re going to verify DHCP by connecting our management station to the lab network and joining it to the domain.  This should be a clean installation of windows 10 in a virtual machine with vmware tools installed.

In the Cortana bar, type control panel and hit enter:


Click the drop down next to view by: and select small icons:


Double click on System:


To the right of Computer name, domain, and workgroup settings click “change settings”


Click Network ID:



Select “this computer is part of a business network…” Click Next:



Select “my company has a network with a domain”. click Next:


On the information screen click next.

On the “Type your user name, password, and domain name, enter:

  • User: administrator
  • Password: Pass123
  • Domain:

Click Next:


On the type computer name and computer domain name screen, enter

  • Computer Name: pc01
  • Computer Domain:

In the enter domain user name and password screen enter the following:

  • User: administrator
  • Password: Pass123
  • Domain:

Click OK:


If everything is working, you will be advised that you’ll need to restart your computer.  Click finish.

After complete the wizard, you will be place back at the system properties screen.  Click ok.


Click Restart Now:


After the computer restarts, Select other user at the logon screen:


Log on using the account we created in the active directory domain services exercise:

(logon, password) user1/Pass123


If you’re able to log on Congratulations!  You’ve built your basic infrastructure and We’re ready to start installing Active Directory Certificate Services.

In the next post, we’ll install Active Directory Certificate Services.






PKI for Network Engineers (1/3): Theory



Greetings programs!

This is the first post in what will be a 3 part series on PKI for network engineers.  The objective of the series is to give a high level overview of the technology, create a basic build using Windows active directory, then use the PKI to do some useful things.

I’m not going to go in-depth on any of the topics, nor is it going to be a basic click-by-click walk-through.  My intention is to seek a middle ground where the reader can with a minimal investment in time and effort, build their own pki and use it, understanding the fundamentals of how it works.  I’ll reference suggested reading if you would like to go deeper into a given topic.

What is a PKI and what is it good for?

PKI is an acronym for Public Key infrastructure.  It provides a salable means of requesting, creating, distributing, validating, and revoking digital certificates.  There are public PKI providers such as Verisign, Network solutions and Godaddy, but these are very expensive and you would normally limit their use to services offered over the public internet.  For organizational and personal/labbing use, it makes more sense to create a private, self administered PKI.

Practical uses of private PKI:

  • Validate the identity of intranet sites and applications to users and other applications
  • Identify and Authenticate devices and users for access to:
    • wired networks
    • wireless networks
    • Virtual private networks
  • Machine to machine authentication
    • DMVPN

Think of a digital certificate as a passport.  It has all sorts of useful information in it, and the passport comes from a trusted authority.  With our own PKI, we can define what information to put certificates, and we can with the help of windows active directory, deploy the certificates to large numbers of devices, services, applications, and people in an automated fashion.


Cryptography basics

Before we go any farther, we need to review some cryptography basics.  I’ll try to make this brief.  If you want more details, check out the suggested reading at the end of blog post.

The goal of cryptography is to provide 3 services to it’s users: Prove data has not been modified, keep it secret, prove the identity of the sender.

Here’s a pattern outline breakdown that associates these services with the tools that provide them.

  • Integrity
    • Guarantee that the information has not been tampered with
      • Provided by hashing algorithms
  • Confidentiality
    • Making information private
      • Provided by encryption algorithms
        • Typically uses symmetrical keys securely exchanged using an asymmetric key pair
  • Authenticity/non-repudiation
    • Verifying the identity of an entity or the identity of an information source
      • Digital signatures
      • Asymmetric key pairs

Encryption Types

There are two types of encryption used in PKI, symmetric encryption and asymmetric encryption.

Symmetric encryption is straightforward.  Both sides of use the same key to encrypt and decrypt information.  Because this is the fastest type of encryption, it’s typically what’s used for bulk data (such as a webpage encrypted with TLS).


Symmetric Encryption

Common Symmetric encryption Algorithms include:

Data Encryption Standard (DES) (and 3DES)

Rivest’s Cipher Version 4 (RC4)

Advanced Encryption Standard (AES)

While I’m not going to go into the details of these algorithms, it’s worth noting that DES is insecure and outdated, and 3DES is computationally expensive because it takes multiple passes.  AES however can do single pass encryption with up to 256 bit keys, making it the encryption algorithm of choice for VPN and other bulk data applications.  I recommend kicking DES/3DES to the curb and using AES as the default for your VPN configurations.


Asymmetric encryption is quite a bit more complex (and computationally expensive).  It uses two mathematically related keys for the encryption and decryption process.  These are public and private keys.  If one is used to encrypt information, it can only be decrypted with it’s counterpart.   The public key can be distributed to anyone, and the private key should be held and used only by it’s owner.



Asymmetric Encryption

In this example the following happens

  1. The owner of a private key encrypts a document with her private key
  2. The recipient receivesthe documents along with a digital certificate with the public key
  3. The recipient tests the certificate for validity
    1. Is the SHA thumbprint correct
    2. Is the certificate expired?
    3. Does it chain back to a trusted root certificate?
    4. If the Authority information access valid?
    5. Can I retrieve the Certificate revocation list from the location in the CDP extension of the certificate?
      1. If so, make sure the certificate is not revoked
  4. The recipient decrypts the cipher text with the public key

Note that this process can and often works in the reverse, i.e. A message can be encrypted with the public key and then decrypted with the private key.


Because the process is computationally expensive, Asymmetric encryption is not used for bulk data.  It’s two most common uses are:

  1. Secure exchange of symmetric keys
  2. Digital signatures

As you might surmise asymmetric and symmetric encryption are often combined. If you want to know more about how that works, check the end of the blog post for suggested reading.

Ok, so now we’re providing authenticity and secrecy, but we’re not proving that the data hasn’t been modified.   Enter the cryptographic hash.

Hashing and Digital Signatures

Hashing algorithms have been an essential part of computer science since the beginning.  You many know them by another name:  the checksum.  The idea is to take data and run it through an algorithm that generates a mathematical result.  That result is called a hash.  Any change, even one bit, would change the product of the algorithm and produce a different hash value.  In this way it can be mathematically proven that the data has not been modified.

The most commonly used algorithms in cryptography are:

Message Digest 5 (MD5)

Secure Hash Algorithm 1 (SHA1)

Secure Hash Algorithm 2 (SHA2)

Please note the following: MD5 is no longer considered secure, and as of January 1 2017 a number of large companies including Microsoft will be deprecating the use of SHA1.  It strongly recommended to use SHA256 or greater in the creation of digital certificates.

A digital signature is the hash value of a text file that has been encrypted with the private key of the sender.  In this manner both the identity of the creator and the integrity of the file can be proven.  It is important to note that the file itself is not encrypted, only the hash.

Ok, this concludes our cryptography review.  Now, we’re going to take an overflight of PKI.

PKI Basics

Digital Certificates

Digital certificates are the foundation of PKI.  They’re digitally signed documents that operate like a passport of sorts.  They can be issued to People, Computers, tablets, phones, routers, switches, applications, or services.  Digital certificates are issued by a Certification Authority (CA).

The typical digital certificate includes:

  • Information about the entity the certificate has been issued to.  This is called the subject.
  • Information about the issuing Certification Authority
  • The public key from the public/private key pair
  • The cryptographic suites supported by the certificate
  • Validity and revocation information
  • Extensions in the certificate. Common extensions include
    • Authority information access (AIA)
    • Certificate Revocation List (CRL) distribution points (also called CDP)
    • What purposes the certificate can be used for (key usage)
    • Subject Alternative Name (SAN)
    • Basic Constraints


x.509 v3 fields.  Image Credit: Windows server 2008 PKI and certificate security

Certificate Revocation Lists (CRL)

All certificates have a validity period, which means they have an expiration date.  But what if a certificate is issued to an employee and they leave the company?  Revocation is a key feature of digital certificates, and a certificate without valid CRL information will not be trusted by most modern applications.

It’s critically important to ensure that the CRL distribution point (or optionally Online Responder) is accessible to all users of a PKIs certificates, or those users will receive errors.

Certification Authorities

A certification authority is…well the name is the recipe right?.  So what does it do ?

  • Processes certificate requests
  • Issues certificates
  • Manages certificate revocation

Certification authorities are typically implemented in a hierarchy.  For most private organizations, a two level hierarchy of an offline root and one or more subordinate issuing CAs are adequate.  Larger or more complex organizations implement a three layer hierarchy that consists of the root, intermediate, and finally the issuing CAs.


Typical 2 tier hierarchy

While it’s certainly possible (not to mention super easy) to make a root CA an issuing CA, it’s highly inadvisable in a real world deployment.  Besides the inevitable scaling issues,  It’s important to understand that the trustworthiness of all the certificates issued in a PKI hinge on the security of the private key of that root CA.  If the root CA were to be compromised and the private key stolen it would be a disastrous, with potentially grave implications for any organization that relies on it.

An attacker with the private key of the root CA in his possession, could use that private key of the root to create their own CAs, or heck, issue whatever certificates they want.  Every device that trusts that root now trusts the attackers bogus certificates.  If an organization has a large number of certificates issued via that trusted root and those certificates are an integral part of business operations, this is not an easily rectifiable situation.  It’s not just a matter of replacing certificates.  An entirely new PKI would have to be rolled out and the compromised root certificate removed from all devices.

For the reasons states above, *any* production PKI should use an offline root.  Never use the root to issue certificates, ever.  It’s worth the extra 60-90 minutes to set up an issuing CA.


This concludes part 1 of PKI for network engineers.  In part 2, we’re going to build a PKI and test it.


Suggested reading:

Windows Server 2008 PKI and Certificate Security

Publisher: Microsoft Press
Release Date: April 2008
ISBN: 9780735625167

PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks

Publisher: Cisco Press
Release Date: February 2011
ISBN: 9781587059162



IPv4 redistribute connected gotcha

In Cisco IOS, when you are redistributing between routing protocols, redistribution is not transitive, with connected networks of the source protocol being excepted.  However, if you explicitly redistribute connected, then the exception is removed and all connected networks must be explicitly redistributed.  It can be a bit confusing, hence the reason to break it down and write about it.

Let’s set up an example and observe the behavior.

We’ll make R1 a border router between RIP and OSPF.  R2 will be an OSPF router.



R2’s routing table:  r2.png

Now, let’s redistribute R1’s loopback into OSPF and see what happens:



The loopback is advertised, but the network has been withdrawn.

Let’s redistribute our loopback into RIP instead


Now we got nothin’:


To break it down, there’s two things happening here:

  1. Redistribution is not transitive.
    1. i.e. protocol 1->protocol 2->protocol 3
      1. Protocol 3 will not get protocol 1’s routes
        1. connected counts as a protocol*
  2. The above rule is bent for connected when not explicitly redistributed
    1. The moment we redistribute connected into the protocol the transitive property is instated for connected routes.  This includes links the are covered by the source protocol.  I.e. the interface running RIP is considered to belong to connected before it belongs to RIP

Any time you’re asked  to redistribute connected into a border router, be mindful to pick up any additional interfaces that need to be seen by the destination routing protocol in your route map.