IIS SSL/TLS Certificate Setup – External CA

Simplistic, works for me, in my given scenario.

Create Certificate Request:

From the IIS server needing the new certificate, open IIS Manager:

- In the left window pane, select the server.
- In the center window pane, select "Server Certificates".
- In the right window pane, select "Create Certificate Request".
- Enter the information in the pop up window.
- Cryptographic Service Provider:
	"Microsoft RSA SChannel Cryptographic Provider"
- Bit Length:
- Provide a path and a name for the request certificate:

The copy/paste the csr.txt text in the request form in the certificate authority’s web interface, or submit the request file to the certificate authority.

Install the SSL Certificate:

Once the certificate authority has provided you with the new certificate, log back onto the IIS server that you created the request on and open IIS Manager:

- In the left window pane, select the server.
- In the center window pane, select "Server Certificates".
- In the right window pane, select "Complete Certificate Request…".
- In the pop up window:
	Select the new certificate.
	Add a friendly name to help ID it.
	Select "Web Hosting".

Bind to the new certificate to the web site:

- In the left window pane, select the web site 
	Possibly "Default Web Site", or maybe not.
- In the right window pane, select "Bindings…".
- In the "Site Bindings:" pop up, choose add or edit.  I'm doing edit here.
- Select "HTTPS" and click the "Edit" button.
- Select the new certificate.
- In the right window pane, restart the service.

Use a web browser to check the site and the new certificate expiration date.

Microsoft PKI – Single Tier Server (Graphical Setup)

If you have not already read the first page in this MS PKI series, 
you should do so before continuing.

The following is useful for setting up a single ADCS PKI server in a very small environment such as a lab. It provides instructions using the standard graphical interface that most people use in the MS world. It uses LDAP for all publishing the CDP/AIA points to computers that are only on the domain.

 If HTTP is needed to publish CRL/AIA, it must be on a different server (Maybe, I’ve had issues getting CRL/AIA publishing to work on the same server).  The requirements can be used from the “Two Tier” setup instructions located on a different page.

Note that a single tier PKI is not typically appropriate in a production environment.

A second page is provided elsewhere that uses a mixture of command line instructions, both PowerShell and the certutil interfaces, for building and configuring the server.

Build up the server and add to the domain.

Copy CAPolicy.inf to C:\windows  (%systemroot%) of root CA server. A simple minimal example is provided below. You must do this step prior to installing the CA role.

Warning:  If creating a new replacement issuing (including single tier) server, use the CAPolicy.inf with the “LoadDefaultTemplates=0” line added.  When server is ready to issue, manually add the certificate templates.

CAPolicy.inf example for Root CA:

Signature=”$Windows NT$”

Install CA Role:

Enterprise root CA
"Certification Authority"

Configure ADCS:

"Certification Authority"
"Enterprise CA"
"Root CA"
"Create Private Key"   -- RSA default is ok,key length 4096, SHA256
"Common name"          -- Not the same name as the server
"Validity period"      -- Should be set by CAPolicy.inf, or equal to.

After complete, check the certificate with MMC CertSRV.  It should match above settings.

Post Install Configuration:

Open command prompt as administrator. Don’t make these too short if using LDAP. Consider OCSP instead.

NOTE: There are many settings. These are pretty minimal.

Certutil -setreg CA\CRLPeriodUnits 1 
Certutil -setreg CA\CRLPeriod "Weeks" 
    --Next two if CRL Deltas are used (which I usually don't on single tier testing server) 
Certutil -setreg CA\CRLDeltaPeriodUnits 1 
Certutil -setreg CA\CRLDeltaPeriod "Days"

Add the CDP and AIA points:

From Server Manager:

"Certification Authority" (MMC CertSRV) 
"Extensions" tab

Don’t screw these up or you have to start over because issued certs will be bad.

Add CDP (CRL Distibution Point):

Click ADD, use as examples and add LDAP path utilizing “Variable” and Insert.


ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

Check "Publish CRL's to this location","Include in CRL's", "Include in the CDP extentions of issued certificates"

Remove default ones except C:\windows (standalone - so no file, ldap, anyway) 
    -- or -- 
Uncheck all boxes for each. 

Add AIA  (Authority Information Access):

Click ADD, use as examples and add LDAP path utilizing “Variable” and Insert.

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

Check "Include in the AIA of issued certificates"

Remove default ones except "C:\windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt
   -- or -- 
Uncheck all "Publish/Include" boxes for each. 

Restart the Service and Publish CRL (certutil -crl):

Restart certificate services to activate this configuration in a PowerShell window:

restart-service certsvc
R-click "Revoked Certificates"
All Tasks, Publish

C:\Windows\System32\CertSrv\CertEnroll – .crl’s date modified should change when CRL is published.

Check PKI health:


Also check “Manage AD Containers” from the pkiview menu.

If CA Object Access Auditing is needed, see the page here.

Microsoft PKI – PKI Health (pkiview)

pkiview.msc is a graphical tool that helps immensely with checking the overall function of your Microsoft PKI setup.

Use pkiview.msc:

PowerShell (as admin), type the following:


Up front, it is pretty explanatory. You will see if something is not correct in your setup.

Also, view the CA containers in AD:

R-click "Enterprise PKI" 
"Manage AD Containers"
Check each tab to see if everything is functioning OK.