There have been a number of questions about Active Directory (AD) schema requirements for the Windows PKI features so I decided this deserves a blog post.

Cheat sheet

1. Version 2 and Version 3 certificate templates require Windows Server 2003 (version 30) or later schema. It doesn’t matter if CA that issues them is based on 2003, 2008, or 2008 R2 server.

2. Credential Roaming requires schema that was shipped in Windows Server 2008 (version 34) OR older schema that is extended manually as documented in this white paper.

3. Certificate Enrollment Web Services require schema that was shipped with Windows Server 2008 R2 (version 47).

Frequently Asked Questions

Q: Does Windows 2008 CA require AD schema update?

A: No.

Q: But Brian Komar’s book says it does?

A: Still no. This is simply an error in the book.

Q: Does Windows 2008 R2 CA require AD schema update?

A: No, but see #3 above. If you actually want to use new web services, you need 2008 R2 schema.

Alex Radutskiy

Senior Program Manager, Windows Security

The following text is a simple copy/paste from the TechNet article How Certificates Work (section How Certificates are Created). Why am I posting this information to the blog? Quite simple: I recognize that it is often overlooked that the key pair generation is always the very first step of a certificate creation.

Certificates are issued by a CA, which can be any trusted service or entity willing to verify and validate the identities of those to whom it issues certificates and their association with specific keys. Companies might issue certificates to employees, schools might issue certificates to students, and so on. Of course, a CA’s public key must be trustworthy or the certificates it issues will not be trusted. Because anyone can become a CA, certificates are only as trustworthy as the authority that issues the underlying keys.

The following six steps describe the process of requesting and issuing a certificate.

1. Generate a key pair - The applicant generates a public and private key pair or is assigned a key pair by some authority in his or her organization. (at a command-line, this part is covered by any certreq –new command)
2. Collect required information - The applicant collects whatever information the CA requires to issue a certificate. The information could include the applicant’s e-mail address, birth certificate, fingerprints, notarized documents — whatever the CA needs to be certain that the applicant is who he or she claims to be. CAs with stringent identification requirements produce certificates with high assurance — that is, their certificates generate a high level of confidence. CAs themselves are said to be of high, medium, or low assurance (at a command-line, this part is covered by any certreq –new command).
3. Request the certificate - The applicant sends a certificate request, consisting of his or her public key and the additional required information, to the CA. The certificate request, which is signed with the client’s public key, can also be encrypted by using the CA’s public key. Many requests are made by using e-mail, but requests can also be sent by postal or courier service — for example, when the certificate request itself must be notarized. (at a command-line, this is done with certreq –submit)
4. Verify the information - The CA applies whatever policy rules it requires to verify that the applicant should receive a certificate. As with identification requirements, a CA’s verification policy and procedures influence the amount of confidence generated by the certificates it issues.
5. Create the certificate - The CA creates and signs a digital document containing the applicant’s public key and other appropriate information. The signature of the CA authenticates the binding of the subject’s name to the subject’s public key. The signed document is the certificate.
6. Send or post the certificate - The CA sends the certificate to the applicant or posts the certificate in a directory, as appropriate (at a command-line, this is done with certreq –accept)

A whitepaper on Certificate Revocation Checking in Windows Vista and Windows Server 2008 has been publshedon Technet here - http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspx

On May 9th, 2009 Entrust Managed Services (provider of HSPD-12 certificates) performed a key update ceremony on the Entrust Managed Services Root and SSP certification authorities. HSPD-12 certificates issued after May 9th, 2009 will not work on the Windows XP operating system (i.e. RTM, SP1, SP2 and SP3).

More information can be found in the Document HSPD-12 Logical Access Authentication and Active Directory Domains.

A new deployment guide was published on Windows7 BranchCache.

It covers the PKI requirements for this feature along with other deployment procedures.