Teach Me How to Route

PKI – Part 3 : RDP Certs

Pesky Warning Messages

If you’ve ever found yourself remoting into a machine, you’ve likely encountered that pesky and rather annoying message that the servers certificate can’t be trusted.

We know, you could, you could just select that little checkbox that says “Don’t ask me again for connections to this computer”, but that’s not what we’re going for.

Getting Rid of Self-Signed Certs

We want to use our enterprise PKI to get rid of self-signed SSL certs, and that’s reasonable. Self signed certificates are impossible to track effectively and many systems will refuse to connect to a system with an expired certificate, and that’s good.

While RDP doesn’t necessarily have that issue because it will generate a new certificate when the original expires, it’s something that we could also leverage our PKI to do.

Creating our Certificate Template

This one is a rather simple and easy one for us to do, let’s open the Certification Authority MMC snapin and get to managing our Certificate Templates.

With the Certificate Templates Console open, right click the “Web Server” template and click “Duplicate”.

Open the “Security Tab” and provide the following permissions to the following Active Directory Objects:

  • Domain Controllers: Read, Enroll
  • Domain Computers : Read, Enroll

We set these permissions so that our Workstations, Servers, and Domain Controllers all have the required permissions to request these certificates and have them automatically issued to them.

Like any template, it’s up for you to really specify the rest such as cryptography, extensions, name, etc. For my template I will be using the following:


  • Provider Category: Key Storage Provider
  • Algorithm Name: ECDH_P384
  • Minimum Key Size: 384
  • Request Hash: SHA256

Request Handling:

  • Purpose: Signature and Encryption


  • Name: RDP-Encr
  • Validity Period: 4 years

Something important you probably do need a little assistance with, make sure you modify the “Subject Name” to “Build from Active Directory Information”:

Setting up Our GPO

Unless you have Remote Desktop Gateway Services installed on everything, the only way to ensure that everything uses a specific template is through either the registry or group policy.

Obviously we already know that managing things through the registry isn’t a scalable option. For this we’ll be using Group Policy. To get started, open up the Group Policy Management Console and create a new Group Policy Object.

I’ll be naming my “RDP – Certificate Templates”, the name of this actually eludes the specific setting we are going to be modifying. I hope you remember the name of your certificate template, because you going to need that moving forward.

In the editor for the GPO, Navigate to the following:

Computer Configuration -> Administrative Templates -> Windows Components -> Remove Desktop Services -> Remote Desktop Session Host -> Security 

Once here, locate the settings “Server authentication certificate template”, open it and specify the name of the template we just created.

Once you’ve done this, you can close everything out and link that GPO to your desired location. Since I want everything in my lab domain to have a CA signed RDP certificate, I’m just going to apply it at the root and force a group policy update to demonstrate it real quick.

Before I demonstrate, I’m just going to validate the the server has receied the correct GPO settings via:

gpresult /h <path-to-html-report>

As you can see, the setting is applied as expected. The RDP Service will request a new cert next time I connect and if I use the proper DNS name to connect, I should not receive any errors.

Testing It Out

First, we’re going to test this out to make sure that when I connect, I don’t get a certificate not trusted error.

Other Thoughts

I thought about enabling TLS1.2 on these, but there’s a few issues with that:

  • Not supported in Group Policy, has to be done through registry.
  • There are known compatibility issues with forcing RDP to use TLS1.2, mainly because you have to disable all other version of SSL and TLS.
Posted in PKITagged , , ,

PKI – Part 2 : Smart Cards

I began writing this one shortly after I wrote my last. As of current, it’s the 11th of January at 1AM and I can’t find the care to go to sleep. Looking back at past posts I noticed that I seem to post these in waves when I get the motiviation.

Typically I’ll spend anywhere from 2-3 hours planning these our and another 2 hours actually writing them. I’m not exactly the greatest wordsmith so I constantly find myself with writers block trying to find out what words go next on the page.

I also try to write my posts in such a way where both the lab and the material are useful. Even if one doesn’t necessarily completely understand the topic, I aim to provide enough information so they aren’t lost in the sauce. Sometimes I execute this better than others. Sometimes I’ll even find myself going to far in depth and loosing myself in the sauce.

Think with your dipstick, Jimmy.

Okay, I get it, I often ramble on for too long to preface these posts, but today we’re going to be talking about something I hold near and dear to my heart, and that just happens to be Smart Card Logon. Those of us with experience in the public sector or military already know what these are and often times how much of a pain they can actually be.

But from an authentication perspective, they’re about as bullet-proof as you can get without exponentially increasing the costs of your infrastructure.

And that’s the focus I take. Industry certifications focus on reducing the risk involved with our systems to acceptable levels, but I don’t quite think that cuts it. Our focus should really be on reducing the ROI for attackers. Sure, there are always going to be well finances groups backed by large organizations and states, but the majority of attacks are actually performed by the lowest of hanging fruit. Low hanging fruits are always looking for the easiest for us to pick by decreasing their ROI from attacks. Anyway, coming back from my tangent. I still don’t get where I was going with that. I’ll probably never know.

Back to Smart Cards.

One of the most prevelant attacks in the industry is credential theft and credential stuffing. This is because of the inherint weakness of username and password based authentication. This is caused because of:

  • Poor credential hygene.

We get it, users don’t want to be bothered with creating complex passwords every three months, but we also don’t want to let them use the same complex password forever. Re: eBay.

We’ve come along way in that we can supplement this with multi-factor using one-time passwords, but those aren’t bulletproof either. in your organization wants to be forced to use a Yubikey, no one wants to be forced to install an app on their phone, no one.

And that’s understandable. This often leads to users enrolling into multi-factor authentication using their phone number, and don’t even get me started on that.

That’s where smart cards can provide us with something.

Everyday, we badge in and out, we don’t think about it, we just do it.

We already have an ID that provides us access to physical locations, why not make this the same thing that gives us access to electronic systems?

Anyway, here’s how smart cards work from an authentication perspective:

  • Users are provided a private and public key pair for the special purpose of Smart Card Logon.
  • These private key is loaded onto a physical token, most often in the form of an ID card using PIV compliant chips.
  • These private keys are protected with a PIN that only the end user knows, which is required to perform signing operations with this key.
  • When a user authenticates using a smart card, they are essentially signing an authentication request using their private key, this is validated against their public key which is published to Active Directory.

What do I need to get this setup?

To get started, you’ll need the following:

  • An Enterprise Certification Authority, see Part 1 of this series.
  • A Smart Card Reader.
  • A Smart Card, or PIV Compliant USB Token.

For my setup, I chose some stuff that’s readily available on Amazon, although if you’re subject to supply chain regulations, you might want to work with a more reputable vendor:

  • PIVKey C910 Smart Card
  • HID Omnikey 3121

Links for these will be provided at the end of the post.

A sad day in history.

Unfortunately, most of the commercially available smart cards only support RSA Keys with a maximum length of 2048 bits. So if you were hoping to use ECC, you’ll be dishing out probably at least triple the money for each card.

Configuring Certificate Templates

The first thing we’re going to need to do before we get any further is configure some Certificate Templates on our CA. To do this, open the Certification Authority MMC Snap-in and right click certificate templates, click “Manage”

We’re going to create two certificate templates here, and lets discuss those real quick:

  • A Certificate Registration Agent, used for enrolling on behalf of other users.
  • A Smart Card Logon, used for actual smart card logon.

I know what you’re going to say, these templates already exist, why can’t I just publish them and use them?

Well, you don’t want to.

First off, the Smart Card Logon does not allow you to enroll on behalf of by default, and second off all of the included templates are configured for older devices such as Windows Server 2003 and Windows XP. We need to get these updated so they support some of the newer features.

Smart Card Template

To get started, right click the “Smart Card Logon” template and click “Duplicate”

In the first window labeled “Compatibility”, Select the operating system of the oldest CA in your environment, as well as the oldest operating system in your environment. My Lab environment is all Server 2016 and Windows 10, so I’ll be going with the newest stuff available for me.

Next up, navigate to “Request Handling”, change the following:

  • Purpose: Signature and Smart Card Logon
  • Check: Allow Private Key to Be Exported

The reason we want to enable the private key to be exported is simply because when we’re creating these, we’ll be creating them on behalf of other users and will need to export the private key to the smart card in order for all of this to work properly.

Next up, go to “Cryptography”, change the following items:

  • Provider Category: Key Storage Provider
  • Algorithm Name: RSA
  • Minimum Key Size: 2048
  • Request Hash: SHA256

You don’t have to follow these exactly, but these are just what I’ve validated to work, and what I’m configuring in my environment.

Next, navigate to “Issuance Requirements” and change the following:

  • Check: This number of authorized signatures (1)
  • Policy Type Required in Signature: Application Policy
  • Application Policy: Certificate Request Agent

These configurations are what is actually going to allow us to enroll on behalf of other users. We’ll later issue our self a certificate with this application policy so we can sign these requests and issue certificates for other users.

Next, navigate to the “General Tab” and give your template a name, I’m naming mine “Smartcard – Managed Enrollment” since I’ll be managing the enrollment of other users with this template. Next, specify the validity period and check publish the cert to AD.

Certificate Request Agent Template

Next up, create a duplicate of the Enrollment Agent template. Following the same steps to setup the cryptography, compatibility, and create the template.

I won’t show pictures from this, just follow the general guidelines doe the Smart Card one, do not do the following though (unless you have bigger plans):

  • Don’t configure the Issuance Requirements
  • Don’t configure request handling

A note here, if you’re not going to store this on a smart card and only plan on storing it in your local certificate store, you can use ECC. Also, if you do plan on using a smart card for this, make sure you make the private key exportable.

Next up, it’s time to publish these to AD so we can use them. To do this, go back to your Certification Authority, right click the Certificate Templates and select “New”, click “Certificate Template to Issue”

Find the template you created and click “Ok”, do this for any templates you have created. Next, verify that these are published. Depending on your account permissions, you may need to go back and change the permissions on the templates. I’m using my Domain Admin account here so there’s no requirement for me to change anything. When it comes to issuing and enrolling in these, I’ll just elevate my session.

Issuing Certificates

Now comes the time to actually enroll and issue certificates. First off, we need to enroll ourselfs in the Certificate Registration Agent certificate we created, to do this open MMC and add the Certificates snapin. If you’re like me and doing this from your normal user account, you’ll need to elevate to admin to do this properly.

In the snap-in, right click, select “All Tasks” and click “Request New Certificate”

If you haven’t already, make sure the computer you’re using has the new Root CA certificate installed in it’s trusted stores, otherwise your computer won’t see any templates you can request.

Since we’re given the permission to enroll in this, all we need to do is click “Enroll”

Next up, let’s enroll my normal user account for Smart Card logon. To do this, right click and select “Advanced Operations”, click “Enroll on Behalf of”

Next, you’ll be asked to select a certificate to sign the request with. Choose the Certificate Registration Certificate we just issued.

Click “Next”, select the certificate we wish to enroll another user in

Click “Next”, now we need to select the user we want to enroll. Be sure to change the default location from your location enrollment workstation to the AD Domain the user resides in. For some reason it always select the local computer.

Next up, click “Enroll”, once complete you will receive a success message (hopefully), you can either select another user or click close.

Now that we’ve enrolled that user, right click their certificate and click export. Ensure that you export the private key as well, remember where you saved this as we’ll need it later to load onto the card.

Setting Up the Smart Card

Before we go too much farther, first make sure your smart card is in hand and your card reader is plugged in.

Once you’ve done that, download and install the PIVKey admin tool from Taglio: http://pivkey.com/download/pkadmin.zip

Once installed, we’ll also need to modify the following registry entries:

Registry Hive: HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Smart Card Key Storage Provider
Key Name: AllowPrivateExchangeKeyImport
Value: 1
Key Name: AllowPrivateSignatureKeyImport
Value: 1

The reason for this is that Windows doesn’t by default allow us to import private keys to a smart card, modifying these registry values allows us to do so without issue.

Next up we need to delete the existing keys, if any from the card. If you bought the card on Amazon or in quantities of less than 25, it probably has the Default PIVKey certificate on it.

Open Command Prompt as Administrator, when prompted for a PIN type the default pin of “000000”. I’m going through this process to show you how to delete certificates off the card, but I’ve already deleted the default one and loaded my own, so I’ll just delete my own.

Type the command:

certutil -scinfo

You will be looking for the Key Container ID, this will look something like this:

Now that you’ve got that, you can issue the command with certutil to delete the key container from the device:

cerutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" <cert-id>

When done correctly, you will be asked for the pin. Again, the default is “000000”

Next up, lets load our new key, you can validate that there are no other certs on the card by using “certutil -scinfo”

The command to load the certificate is:

certutil -v -csp "Microsoft Base Smart Card Crypto Provider" -p <pw> -importpfx <pathtopfx>

You can validate the card is successfully loaded using the “certutil -scinfo” command.

Now that the keys loaded, we should change the default pin. To do this, change your working directory in command prompt to:

C:\Program Files (x86)\PIVKey Installer\PIVKey Admin Tools

Next run the commad:

pivkeytool.exe --changepin <new-pin> --userpin 000000

I do want to actually mention that there is a GUI Interface included for managing the smart card, but I wanted to focus on an agnostic way of doing this for the most part, if you’re interested in using the GUI, you can find it in your AppData folder.

One last thing, I know, it continues. Now all we have to do is map that certificate to the appropriate PIV slot on the card:

pivkeytool.exe --mapdefault --userpin <userpin>

Domain Controller Certificates

Now I’m not going to walk through the full steps here, I’m just going to tell you what you need to do to set this up for Smart Card Authentication.

  • On your enterprise CA, make the Domain Controller Authentication Template published to AD.
  • On your Domain Controller(s), enroll in a Domain Controller Certificate issued by the new CA.

Logging in with the Smartcard

Now that we’ve got the card loaded and PIN changed, let’s validate that we can login. I’m going to remote into my file server using my user account that I’ve temporarily added to the remote desktop users on that computer.

As you can see, we ran into some issues there with passing the smart card credential through RDP. This is normal when you don’t have the Mini-driver installed on the computer you’re remoting into. That can be fixed by simply A) installing the minidriver, or B) uninstalling the minidriver on the computer you’re using to remote.

Additional Thoughts

If you you really want to use smart cards to their full capability, you want to ensure that Smart Cards are required for interactive logon. This is a setting in the AD Object of a user that actually randomizes the hash to protect against pass the hash attacks and also ensures that users can’t login without their smart card.





Posted in PKITagged , , , , , ,

Public Key Infrastructure – Part 1

It’s been over a year since I’ve last posted and that’s primarily because of life smacking me straight in the face. Between studying for college, certification exams, and the recent news of our Baby Girl on the way, I just haven’t had the time to sit down and write a meaningful and well thought out post.

In the months since my last post, I’ve also added some pretty cool certifications to my resume, most of them I actually did within the last month:

  • ITILv3 Foundations
  • CompTIA A+ (I know, really? Part of my degree program)
  • EC Council Certified Encryption Specialist (ECES)
  • ISC2 Systems Security Certified Practioner (SSCP)

Next weekend I’ll be taking the ISC2 Certified Cloud Security Professional (CCSP) Exam, so I should be adding that one to my resume as well. I’m excited and enjoying focusing a lot more on security than networking, the enjoyment I got out of networking had begun to grow stale.

I still find a good amount of enjoyment out of it, but not the amount I used to where I would often find myself up for 3 days straight off of the pure chemical rush of learning and labbing things out.

Turn’s out you’ll wait no more. Today’s discussion will be part 1 of a multi-part discussion on PKI. This post will primarily focus on building a two-tiered PKI infrastructure using Active Directory Certificate Services.

Here’s what the other parts will cover:

  • Part 1 – Building a Two-Tiered PKI
  • Part 2 – Configuring and Setting Up Smart Card Logon and Smart Card based EFS
  • Part 3 – Configuring Automatic Enrollment and Certificate Selection for RDP
  • Part 4 – Federating login with Office 365 and Providing S/MIME functionality with your on-prem PKI
  • Part 5 – Forget Smart Cards; FIDO, TPM VSC and more

Before I get too far ahead of myself I want to make it clear that I’m assuming you already have an understanding of Asymmetric Cryptography and PKI and because of that, I’ll only describe it with three bullet points:

  • Asymmetric Cryptography – data is encrypted with a different key than it is decrypted with.
  • PKI enables functional Asymmetric Cryptography by providing a backend to validate, issue, revoke and publish certificates to a directory
  • In an asymmetric cryptography environment, users have both a private key and public key. Data encrypted with the public key of a user can only be decrypted using that same user’s private key.
  • For Example:
    • Jane wants to encrypt data to Send to Jon; neither Jane or Jon have exchanged private keys to encrypt the data.
    • Jane will instead reference Jon’s public key stored in their local directory. Jane will encrypt the data using Jon’s public key and also sign the data with her private key.
    • When Jon received the data, he will decrypt the data with his private key, and reference Jane’s public key to validate the digital signature.

The above is a simple example of how such encryption would work. There are a few key distinctions made in this example that I want to highlight before moving forward.

  • Digital Signatures can only be signed by the owner of the private key.
  • Digital Signatures are proof of origin, and in some instances provide evidence of non-repudiation.
  • Digital Signatures are validated using the user’s public key.
  • Encryption of data is only possible using the recipient’s public key.
  • The decryption of data is only possible using the recipient’s private key.
  • In either instance, there is a key-pair generated that contains both the private and public keys. Generally speaking, only the user will maintain possession of the private key. Public Keys are normally published to a Global Address List (GAL) or in Active Directory

For our setup, we’ll be using a simple two-tiered PKI for an enterprise environement. There won’t be a whole lot of things going on, but we’ll show you how to get this setup and working in your environement. The two Certification Authorities we’re going to be creating are:

  • Scorchedwire Media Group – Root CA X1
  • Scorchedwire Media Group – Subordinate CA G1

Based of the names, I’m sure you’ve already made the assumption that there’s some heirarchy here to this setup. This is normal in any PKI.

  • The Root Certification Authority is responsible for issuing certificates to Subordinate Certification Authorities.
  • The Root CA should remain off at all time, other than to patch, manage certificates (issue/revoke) and to periodically publish CRLs.
  • The Subordinate CA will be used to manage all server and user certificates, not including CAs.
  • The Subordinate CA will publish the Root CAs CRLs.

Wait, you mentioned CRL, what’s that?

When a CA revokes a certificate prior to the expiration, a new entry to the servers Certificate Revocation List (CRL) is created. The CRL is what provides systems with the information necessary to establish whether the certificate is valid or not.

Let’s Get Started

To start, I’ve already deployed to Windows Server 2016 Standard VMs. When deploying these VMs, here’s the setup you should use:

  • The Root CA should be offline, and not domain joined.
  • The Subordinate CA should be online, and domain joined.

Installing ADCS

The first task we’re faced with is actually installing ADCS on both the Root and Sub CA. This is relatively easy and can be done through the server manager, under Add Roles and Features.

Additionally, if you’re not one for GUIs or your Root is running Server Core, you could use Powershell.


Anyway, time to get started on the Root CA:

Open the Server Manager, navigate to Add Roles and Features. Navigate to the Role-based or feature based installation and click next.

You’ll find a screen for “Active Directory Certificate Services” , select this and accept the popup asking you to install the management tools as well. You’ll want these for configuring AIA and CRL publication locations.

Go through all the steps, just clicking next. Ensure that when you get to “ADCS -> Role Services” that the only selection is “Certification Authority”, click next and click “Install”

Once the role is installed, there’s a couple things that need to be completed.

  • Configure the Root CA, and generate a Certificate
  • Configure the Root CAs maximum validity period.
  • Configure Root CA AIA and CRL Publishing locations
  • Last, issue a certificate for the Sub CA once we’re complete with the setup there.

You’ll probably notice in the Server Dashboard that there is that notorious yellow caution icon, let’s click that and get to configuring our certification authority.

Some things I think you can do without me showing you pictures, hopefully:

  • Specify credentials, click next.
  • Select Role of Certification Authority, click next.
  • Select “Standalone CA”, click next.

Next up, we need to generate our private key, to do this select “Create a new private key”, and click “Next>”

So what about these crypyography options?

Honestly, that’s all on you and your business requirements. I personally prefer Elliptic Curve to RSA, so I’ll be creating my Certificates with ECC where possible, when we get to smart cards, we’ll have to deal with RSA. I’ll put an section in for my general preferences and recommendations at the end and why I make certain choices.

For my options, I’m selecting

  • Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
  • Key Length: 384
  • Hash Algorithm: SHA384

In the Next Window, I’m only going to specify my Root CA name.

Lastly, the validity period. This is really contingent on your needs, but Root CAs can be valid as long as you feel confident in the encryption and protection mechanisms behind them.

Obviously public and government CAs have guidelines and regulations they have to follow, but for enterprise CAs, that’s really a business decision based on the risk. I recommend no longer than 15 years.

Next up we’ll specify where we want the certificate database and logs to be located. I’m going to move them from the default location to a seperate location. The default location is “C:\Windows\System32\CertLog”

Next up, just verify the options you selected and click “Configure”.

Once, you get it configured, you’ll get a message stating success, let’s move on to the next part.

Configuring Maximum Issuance Lifetime

For those of you familiar with certificate requests, you’re familiar with the fact that you usually specify the desired certificate lifetime in your request. While this might seem like it’s what actually dictates how long your certificate is valid for, it’s actually something else.

Open the registry editor and navigate to the following registry hive:


There are two registry values you may need to edit, these have to do with validity period of issued certificates.

The first one is the only one we will be editing, since the default value for the other one is already set to years.

Key Name: ValidityPeriodUnits
Default Value: 1
We're changing it to: 10

The other one you might want to change, depending on your configuration is:

Key Name: ValidityPeriod
Type: REG_SZ (String)
Default Value: Years

Configuring AIA and CRL Publishing Locations

Open the Certification Authority MMC Snap-in and point it to your CA if it isn’t already.

Right click on your CA name and click “Properties”, open the “Extensions” tab.

I’m going to need to delete all the default entries for CRL Distribution Points and AIA:

Next up I’m going to want to specify the locations that these are stored locally, for this I’m publishing them to the “C:\Certificates\DB” folder.

CDP: C:\Certificates\DB\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: C:\Certificates\DB\<ServerDNSName>_<CaName><CertificateName>.crt

Next up, I’m also going to specify where they will be published on my Subordinate CA. I will have to manually import these, but they’ll be published using an IIS site on my Subordinate CA.

The location for this will be:

CDP: http://ocsp.scorchedwiremedia.net/certs/CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: http://ocsp.scorchedwiremedia.net/certs/<ServerDNSName>_<CaName><CertificateName>.crt

You’ll notice that I selected a few check boxes, make sure you check all of these. Some of these are just for the sake of beauty when pulling up “pkiview.msc”, the others are actually important for telling clients where to look for new CRLs.

Next up, you’ll click “Apply”, and the service will restart.

One more thing we’ll want to do before we continue is set the CRL interval for when CRLs will be published. Since the CA is offline, I’m going to set the CRL publishing interval to every 52 weeks, I’ll have to turn this on next January to publish a new CRL.

To do this, drill down to revoked certificates in and right click “Properties” and set the interval to “52 weeks”, you can also set this higher if you really want to, no need to publish delta CRLs since we won’t be online often enough.

Now, right click the “Revoked Certificates” and click “Publish CRL”, go grab the CRL from the file location on the local disk and export this to a place you’ll remember for later, we’re going to need this when setting up the Subordinate CA.

Setting up the Sub CA

Time to move on to our Sub CA Server. We’ll be going through and installing AD CS on that too, but I won’t go through the pictures on that part until we get to the configuration. The following roles should be installed on your Sub CA, which should be domain joined:

  • Certification Authority
  • Online Responder (we’ll use this in another part of this series, so just install it for now)
  • IIS – for publishing CRLs, for now.

Optionally, you can install the Certificate Enrollment Web Service, which provides a web interface for users to enroll in and request certificates. Since I use the Certification Authority MMC Snapin, I don’t see a need for this as most times we will be enrolling on behalf of other users or users will be automatically enrolled through AD.

Now that it’s installed, the first thing I’m going to do is create an IIS site for the CRLs and Certificates. First I’m going to create the directory “C:\certs” and copy the CRL from my Root CA here then I’m going to create a virtual site for this in IIS Manager.

  • <SERVER-NAME>\IIS_USRS should have read only access.
  • NETWORK SERVICE should have read only access.
  • Authenticated Users should have read only access.

In IIS Manager, I’m going to right click the Default Web Site and select “Add Virtual Directory”, the virtual directory name will be “certs”, pointed to the physical directory “C:\certs”

I’ve also enabled directory browsing so I can navigate to the website and validate the certs and CRLs are there:

Now, in my browser I will validate that the Root CAs CRL I placed there can be reached

Now that we’ve setup all the pre-requisites for our Subordinate CA to validate these CRLs, it’s time to configure our Sub CA:

Go back to the server manager and get rid of that pesky yellow caution icon, it’s time to configuration ADCS.

Again, somethings you can do without me:

  • Enter Credentials, click next.
  • Select “Certification Authority”, click next.
  • Select “Enterprise CA”, click next.
  • Select “Subordinate CA”, click next.
  • Select “Create a new private key”, click next.

Select the cryptography for this one, I’m going to use the same I used on the Root CA:

  • Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
  • Key Length: 384
  • Hash Algorithm: SHA384

The Common name for this CA will be “Scorched Wire Media Group Subordinate CA G1”

Click next, save the Certificate Signing Request (CSR) to the local disk, copy to a location that you will remember as well, we’ll use this to request the Certificate from the Root CA.

Click next, select where you’re going to save the certificate database to, and click configure.

Issuing our Sub CAs Certificate

Now that we’ve generated the request, lets take that and copy it to our root CA server. On the Root CA server, open up the Certification Authority MMC Snap-in.

Right click on your CA, select “All Tasks”, and “Submit New Request”

Select the CSR from your Sub CA, refresh the “Pending Requests” tab, and right click your request and select “All Tasks”, click “Issue”

Next, go to the “Issued Certificates” tab to locate your Sub CA’s certificate. Click “Open”, navigate to the certificate details and select “Copy to File”, use the certificate export wizard to export the public key and copy this to your Sub CA.

Installing the Public Key on Our Sub CA

Next go back to our Sub CA and open up the Certification Authority MMC Snap-in. You’ll notice that the services aren’t started, and that’s because we haven’t installed our certificate yet. Right click your CA Name and select “All Tasks” and click “Install CA Certificate”, in the popup, navigate to and select the certificate you exported in our previous step.

If you exported the certificate in a format that includes the Root Certificate, you should not have any issues with the CA Services starting on your Sub CA. If you get an issue saying that the certificate signature cannot be validated, this is because the Root Certificate needs to be installed in the Trusted Root Certification Authorities certificate store.

Next up, make sure you export the Root Certification Authorities Certificate in the format specified in the AIA locations. If all is done correctly, you should be able to open “pkiview.mmc” and see no errors.

You made it this far:

You made it this far, so you should know a few things that should be done moving forward:

  • Cleanup CRL and AIA distribution points on the Sub CA, there’s some defaults that just need to be removed to avoid issues later.
  • Since the Sub CA is an enterprise CA, all CRLs are already published to Active Directory, so no need to publish them to the IIS virtual directory unless you want to.
  • Think deeply about the cryptography used. Using next-generation encryption where possible will save us all when computing power eventually get’s powerful enough to break RSA 2048-bit keys.
  • If your Root CA is in a production environment and used for actual enterprise certificate services, consider full disk encryption to protect against simple methods used to steal the CAs private key.
  • Consider migrating your IIS to HTTPS once your have your CA setup, if you’re like me, you encrypt everything (even DNS), because you’re paranoid.
  • You’ll notice I’m using the DNS name ocsp.scorchedwiremedia.net, that’s because one of our future updates to this series will cover setting up an online responder for Smart Cards and S/MIME.
  • When we modified the validity period, we didn’t actually specify the validity period of specified certificates. The validity period is actually determined as the intersection of the shortest period between the configured validity period and that on the Signing Request. Therefore, if a CSR requested a cert that would last 5 years, but the CA was only configured to issue certs for 2 years, the cert validity period would be 2 years. On the flip-side, if a CSR requested a cert that was 3 years, but the CA was configured for 5 years, the cert issued would be valid for 3 years.
  • Don’t forget to update the configured validity period on your Sub CA, otherwise all your Certificate Templates will be ignored for validity periods when certificates are issued using them.
  • Don’t forget to harden your CAs, you don’t want them to be breached because you forgot to do your due-diligence.
  • Don’t forget to publish your CA certs to domain joined computers. The easiest way for this is just a Group Policy that publishes the Root CA to the Trusted Root Certification Authorities certificate store and the Sub CA to the Intermediate Root Certification Authorities Certificate Store.

Here’s a good table on the effective strength of ECC vs RSA:

Credit: https://www.globalsign.com/en/blog/elliptic-curve-cryptography/

Posted in PKITagged , , , ,