Microsoft PKI Checklist for 2016
post by: mosesrenegade
Update for 2016: In my home, which doubles as the home lab and testing environment, I have tried to build a new Microsoft PKI suitable for 2016. I use this to distribute all the certificate services certificates across my internal sites. and This guide and checklist should help everyone trying to get a handle on the latest. Specifically since SHA-1 certificates are now actively being denied.
This guide is built on Windows 2012 R2, even though we are very close to Windows Server 2016 being released.
I am building a Two-Tier PKI and you can use this guide to help you build one. I made sure to connect my Offline Root CA to the internet and fully patch it before taking it offline. One of the reasons for this, I wanted to make sure that we had the latest Cryptographic patches and signatures installed.
Offline Root Certificate Authority
Once the machine is patched and named appropriately, we will use the Roles and Features Wizard to install the Active Directory Certificate Services Role on this server.
It will also be important to only choose the Certificate Authority Role on this Server.
Once this is done, you may see a Yellow Triangle at the top near the flag in which will prompt you to configure the Certificate Services on the system.
It always best practice to use a CAPolicy.inf file, I am skipping this at this time, but make sure in a production environment you have this file.
- Standalone CA
- Root CA
- New Private Key
- Cryptographic Provider: ECDSA_P256#Microsoft Software Key Storage Provider
- Key Length: 256
- Hash Algorithm: SHA-256
- CA Name:
- Common Name: Generally <Machine-Name>-CA Can be of your choosing
- Validity Period:
- For the offline root, I decided to use 20 years, because it is my lab.
- Remember, after the time elapses you must Boot the Offline Root and Renew the CA Certificate.
- Certificate Database Location:
- Choose the defaults (unless you have a D:\ drive to use).
Since this is a Standalone CA, do not change the credentials and make sure to choose to configure the Certificate Authority Server. The system should be configured as a Standalone Root CA.
There is a way to do this from the Powershell CLI, like so:
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName "OFFCA1-CA" –KeyLength 256 –HashAlgorithm SHA256 –CryptoProviderName "ECDSA_P256#Microsoft Software Key Storage Provider"
Verify the CA
The following command line will verify that the Root Certificate Authority was setup correctly. Opening a Powershell prompt as an administrative (or an elevated prompt), this is done by right-clicking on the Powershell icon and choosing ‘Run as Administrator’
Find your CRL file in (%Windir%\System32\CertSrv\CertEnroll) as [CAName].Crl
Certuil %Windir%\System32\CertSrv\CertEnroll\[CAName].Crl | findstr /spi algorithm
This should show something like so:
If it shows ‘sha256ECDSA’ then you will have a universally accepted certificate. I had issues with many browsers when it stated : RSAPSS-DSS . This happened because my CAPolicy.inf file contained the following setting:
Do not use this, set it to:
Preparing for Active Directory Rollout
I ran the following settings with the same elevated Powershell Prompt:
- I have changed some of the settings here to match my active directory domain and my active directory CA server directory. I state this for the people that are using copy and paste to CHANGE the URLs to match your environment.
certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:http://www.<domain.local>/pki/%3%8.crl" certutil –setreg CA\CACertPublicationURLs "2:http://www.<SubCADomain.Local>/pki/%1_%3%4.crt" Certutil -setreg CA\CRLOverlapPeriodUnits 12 Certutil -setreg CA\CRLOverlapPeriod "Hours" Certutil -setreg CA\ValidityPeriodUnits 10 Certutil -setreg CA\ValidityPeriod "Years" certutil -setreg CA\DSConfigDN "CN=Configuration,DC=<domain>,DC=<domain>,DC=<domain>" restart-service certsvc certutil -crl
At this point the certificate can be moved to a place in which the online Subordinate CA can get it. The documentation will tell you to move it to the A:\ drive, but with disk drives being in scarcity today, I will just recommend you to move it using the safest way you can.
copy C:\windows\system32\certsrv\certenroll\*.cr* X:\
Please note, at this point you cannot turn off the offline root CA as you will need it to sign the Subordinate CA Keys.
Subordinate CA Setup
The CA Needs to have the following prerequisites:
- Joined to the Domain
Before we start our CA Roles we will install the Root CA on the local machine, copy the files to the system for example:
copy X:\*.cr* C:\Certs\
Now make sure you login as a user who is both an Enterprise Admin and Domain Admin. With an elevated Powershell prompt run the following commands
certutil -dspublish -f C:\Certs\<file_rootCA>.crt RootCA certutil -addstore -f root C:\Certs\<file_rootCA>.crt certutil -addstore -f root C:\Certs\<RootCA>.crl
Next, because my SubCA will also serve as my www address I am going to create a CNAME in my domain controller and link it to my A record for the SubCA. Because we added the CPS and the /PKI directory above using registry entries for CDP and AIA, this is an important step.
Setting up IIS
Here we will setup IIS for the CA. As a shortcut we are going to once again run Powershell CLI as administrator and run the following commands. Do note, I do not have a D:\ drive for this, while I usually do, it is generally good practice to do so.
New-item -path C:\pki -type directory write-output "To View an Example CPS use this link: "https://www.globalsign.com/en/repository/TrustedRoot%20Template%20CPS.pdf" | out-file C:\pki\cps.txt new-smbshare -name pki C:\pki -FullAccess SYSTEM,"DOMAIN\Domain Admins" -ChangeAccess "DOMAIN\Cert Publishers"
Now we will install IIS on this server by using the Add Features Wizard or Alternatively Powershell, although what is below may be a bit much for your environment. I am running this environment as a test lab and as such I am generally installing much more than needed.
Install-WindowsFeature -Name Web-Server -IncludeAllSubFeature -IncludeManagementTools
In order for this server to actually be able to distribute the CDP and AIA information there needs to be a new Site setup. In this case we are going to setup the :\pki directory to map to a directory in the server known as \pki.
Right Click the Default Web Site and choose ‘Add Virtual Directory’.
Make sure to make the Alias: pki and the Physical Path C:\pki.
Click OK and now you will need to set up anonymous access. In order to do this you need to make a few things happen. Click on the ‘Authentication’ button in the PKI virtual directory and on the right hand side choose Edit Permissions. This will give you the same form as if you had right clicked on the PKI folder in the windows explorer.
Under Security tab click edit. On the permissions for PKI form choose Add.
This gets confusing because of how you are going to add users. More or less you are going to add 2 types of users.
- DOMAIN\Cert Publishers
- IIS AppPool\DefaultAppPool
The IIS AppPool is a special object type and to use it, you must change your search to include object type service accounts and change your place to your local server. Here is the other two items to note:
- You cannot choose service accounts if you changed your place first.
- You will not see the right account if you search for it, you must type in the name like it seems above and choose ok.
Make sure to give Cert Publishers Modify privileges. Click ok until your back in IIS.
Next change Request Filtering by double-clicking it. Then click Edit Feature Settings on the right and check the box to ‘Allow Double Escaping’.
In Powershell type the following command:
If the system is ready, you may install the Certificate Authority Roles and Features as we did in the first Offline Root CA setup.
Sub CA Setup
We will install the Sub CA using the following commands in Powershell or alternatively using the Server Manager Add Roles and Features components.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools Install-AdcsCertificateAuthority -CAType EnterpriseSubordinateCA -CACommonName "SubCA-CA1" -KeyLength 256 -HashAlgorithm SHA256 -CryptoProviderName "ECDSA_P256#Microsoft Software Key Storage Provider"
Once this is done we will need to move our Sub CA Certificates back to the Offline Root CA to have the Offline Root CA sign those certificates and confirm the entity.
You will see that there is a request typically by default put into the root of the C:\ drive and with the extension .req. This is the file to move.
There is a nice command line interface on the CA that will allow you to submit the request
certreq -submit file.req
Now that this is done using the Certificate Authority Tool, under Pending Requests Right-Click and issue the certificate.
Then under Issued Certificates you find your certificate
The command line equal to this is:
certreq resubmit <number>
Typically your RequestID will have a number and you can use that number for your request. Because in theory this should be the first real request more than likely it will be 2.
Now you can retrieve this certificate in command line:
certreq -retrieve <Request#> X:\CANAME-ComputerName.crt
Now on the SubCA with the files available type the following commands will copy the cert files over to the pki folder, install the certificate and start the certificate server on your subordinate.
copy x:\*.cr* C:\pki\ certutil -installcert x:\CANAME-ComputerName.crt start-service certsvc copy %windir%\System32\certsrv\certenroll\*.cr* C:\pki\
Finally, just as before you need to make sure to publish the right pathing so that all the clients can find the CDP and AIA.
certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:http://www.www.<domain.local>/pki/%3%8.crl certutil -setreg CA\CACertPublicationURLs "2:http://www.www.<domain.local>/pki/%1_%3%4.crt\n1:file://\\subca1.<domain.local>\pki\%1_%3%4.crt" Certutil -setreg CA\CRLPeriodUnits 2 Certutil -setreg CA\CRLPeriod "Weeks" Certutil -setreg CA\CRLDeltaPeriodUnits 1 Certutil -setreg CA\CRLDeltaPeriod "Days" Certutil -setreg CA\CRLOverlapPeriodUnits 12 Certutil -setreg CA\CRLOverlapPeriod "Hours" Certutil -setreg CA\ValidityPeriodUnits 5 Certutil -setreg CA\ValidityPeriod "Years" restart-service certsvc certutil -crl
This should now build our certificate authority. Turn off your Root CA’s as this should be done.
Test Drive IIS Server SSL
For a test drive, we will enable SSL on the www server and test it with a browser like Chrome just to make sure that everything is working as expected. In order to do this most effectively, I am going to go back into Roles and Features and add the Active Directory Role for Web Enrollment.
Once this is done, we can then later use this to actually request and retrieve our certificate.
First on the SubCA run the following command:
Certuil %Windir%\System32\CertSrv\CertEnroll\[CAName].Crl | findstr /spi algorithm
If everything worked as before then you should see the sha256ECDA string appear.
Open Certificate Authority MMC and Let’s make sure that the WebServer Template is enabled and available.
Choose Certificate Templates and then New Certificate Template to Issue. Choose Web Server.
Next run IIS Manager. Choose the following menu options:
Under the Computer Name find a button for Server Certificates and Double-Click it. Next on the right hand side under actions you will see a Create Certificate Request Option. Choose it.
Make the common name the following:
Fill all the fields of the form out to be able to create it.
Next, choose a secure key size like a 4096 bit key - length.
Finally choose a place for the request, because this server is also the certificate authority we do not have to worry too much about permissions. I called mine www.req.
Next we will open the following URL:
Choose to Submit a New Request and copy and paste the request. Make sure the template you use is marked ‘Web Server’.
Copy the contents of www.req into the first form and choose submit. At this point we should be able to retrieve the certificate and chain.
Finally go back to the IIS Manager and in the same window as the Server Certificate choose to complete the request. You should be able to just point to the .cer file to finish the submission.
Now we need to bind this request to the 443 listener. Under Default websites choose bindings. Add a 443 listener binding and choose the following hostname:
At this point you can distribute your Root CA and SubCA Certificates to all devices that do not have Active Directory joined rights. For Example Internal Linux and OSX Devices.