Hello S-1-1-0, Crypto Guy is on a failboat board again.

Sometimes it is useful to export a certificate template to a file for future use. For example:

• for custom certificate template backup;
• if you have multiple AD forests, you can transfer configured certificate templates between forests;
• share custom certificate template with partners;
• share certificate template when you are making a online learning session;
• etc..

Till Windows Server 2008 R2 release there was no supported way to export (or serialize) certificate template and move it out of band between two forests. With Windows Server 2008 R2 there was the only publically described way to transfer templates between two forests: AD CS: Cross-forest Certificate Enrollment with Windows Server 2008 R2. This whitepaper includes a PKISync.ps1 script (the script was written by a man who first time faced PowerShell, he-he) which copies certificate templates along other AD data between two forests. The downside of this approach is that it requires a two-way trust between forests and performs data transfer online.

Recently I wrote a sample function which allows security administrators to dump trusted root certificates from Microsoft web site.

Microsoft maintains a number of predefined trusted root CAs which are members of Microsoft Root Certificate Program. Here are several useful links on TechNet wiki:

• Introduction to The Microsoft Root Certificate-Program
• Microsoft Root Certificate Program
• Windows Root Certificate Program Members
• Windows Root Certificate Program

In addition, update mechanism is described here: KB931125.

Generally speaking, Microsoft maintains a special certificate trust list (CTL) which is located here. This CTL contains hashes and extended properties for each member of the root certificate program. Also, each certificate is downloadable at:

Update 06.04.2020: clarified the last section by mentioning that everything expressed in this blog post is primary opinion-based.

Update 16.06.2022: updated recommendations on HTTP URL host name.

Information in this article should be used only when you plan ADCS installation.

Hello Internet!

Today I’m going to describe one of the ugliest and, on the other hand, one of the most important topic in PKI — chain building and revocation checking and how to design/plan them by conforming best practices.

Hello S-1-1-0!

In previous post I posted about new PowerShell PKI module release and notable enhancements. Today I’ll talk about less notable and obvious, but useful enhancements.

PKCS#10 certificate request support

I made a support for X.509 certificate requests formed in a PKCS#10 format. The only (currently) class is X509CertificateRequest class which is developed in a similar manner as X509Certificate2. Let’s take a spherical horse in a vacuum sample certificate request which was generated by using certreq.exe tool:

What a great feeling when your blog is up and running! I think, I should post something here while it is still up :)

Today I want to post about new release of my PowerShell PKI module which is released today on CodePlex.

What’s new

1) Introduced module components

After a brief talk with a colleague I decided to split the module in two parts: client and server. Previously my module required RSAT installation in order to use it, while there were a lot of commands which do not require them and are not related to ADCS management. Therefore I divided module in two components: Client and Server. Client component contains commands which are related to local PKI management and do not require RSAT installation. Server component is intended for ADCS management and requires RSAT installation. Here is a module folder structure: