Are "Certificate Templates" used only as a "Template" or do they validate a certificate request?

Question

I'm trying to learn how Microsoft Certificate Templates interact with a certificate request, and can only guess that they take on one of the two/three forms:

1. They simply help the client create a request, EKUs, and other settings for the PKCS10 submission to the server.

2. OR they are used to validate, control, and restrict what exactly a user can do when uploading a PKCS10 request. Kinda like an application level firewall

3. Some combination of the above that either uses data in the certificate, or heuristics to automatically issue or deny a certificate.

What I'm trying to prevent

I want to prevent a user from diverging from the approved templates I've offered them, in any and all ways... in particular, I want to prevent a change of:

• Expiration date
• EKU
• Basic Constraints
• Critical / Non critical sections
• Key usage
• Etc.

... if they paste in the manual certificate request in the enrollment page (that doesn't use a template)

Research

I'm looking at the docs for Certenroll and see there is an enrollment method that uses a template, and a submit method that does not.

I assume the Submit() method from CERTCLILib.ICertRequest3 needs to be run under a controlled service account since anything can be sent to the server, but things aren't too clear from a documentation standpoint.

Since there seems to be some flexibility in using templates at a programmatic level, I'm unsure how to describe the benefits or utility of a Server Template.

Finally, it's possible that the "Application Firewall" for certificate requests, exists in the form of custom code, or Microsoft Forefront Identity Manager, or some other product.

Assistance is appreciated.

Answer 1

In an Active Directory setup, the "certificate templates" are supposed to be used by the clients and by the CA itself ("AD Certificate Services").

For the CA, the templates describe how certificates shall be issued, including:

• The certificate contents, including all the extensions, validity period and so on.
• The issuing conditions, e.g. whether the request must be signed by some authorized RA agent or not.
• The template access rights.

There are many variations, because templates have been enriched along Windows versions (so there are "Windows 2000", "Windows 2003" and "Windows 2008" templates), and the CA itself can be "stand-alone" or "enterprise" -- in the latter case, the CA is supposed to automatically feed on the AD accounts and ACL to know whether a given certificate request shall be honoured, while in a stand-alone CA most requests will be subject to a manual intervention from the CA manager (who will click on "issue" or "deny").

The AD tree contains all the known templates (you can create your own). The CA itself (the AD CS service) will "publish" some of these templates: this is the list of the templates that the service will actually use.

In any case, the contents of the certificate requests from clients will be mostly ignored (except, of course, the public key); the templates decide what goes into certificates, not the request. There are exceptions; for instance, the template may specify that the Subject Name shall be taken from the request, in which case the SubjectDN and the Subject Alt Name extension will be imported "as is" from the request (at configuration time, you may get a warning from the GUI that such a setting in an "enterprise PKI" can be dangerous because whoever is allowed, at the AD level, to request such a certificate, may then put an arbitrary name in there, so you'd better double-check your access rights).

For the client, templates are advisory: they document the kind of certificate that clients may request, and what they should put in the request. For instance, the template may state that clients shall use a specific CSP (Cryptographic Service Provider) to generate the key pair; since the CA cannot actually verify that the specified CSP was used, this is only for the benefit of clients. Some other settings are used by both client and server (e.g. key size).

The template can be used only by clients who have access to the AD server, i.e. within the domain. Clients outside of the domain shall build their requests in any way they see fit, based on information transmitted out-of-band. One usual method, in the Windows world, for an out-of-domain client to generate a certificate request, is to use the certreq.exe command-line tool with a "policy file" and the -new option.

CertEnroll is a programmatic API to be used on the client side; it encapsulates several functionalities:

• CertEnroll can generate a new certificate request (including key pair generation). It may do so by feeding on programmatically-provided request parameters (e.g. key type and size). It may also automatically access the AD server to get the information from a published template.
• CertEnroll can talk to the CA to submit the request.
• CertEnroll locally saves the requests (in a dedicated certificate store) so that, when the certificate is received and imported, the link with the private key (which never left the client machine) can be restored.

---

To sum up:

• Certificate Templates are the method by which you may configure what the CA puts in the certificates it issues, and under what conditions it may issue the certificates.
• Clients are supposed to send requests which "work" with what the CA expects (e.g. key type and size). Clients may use the templates to get that information, if they have actually access to the templates (i.e. the clients are within the domain). Template usage by clients is not mandatory.
• However, when a client requests a certificate, the CA must somehow "know" to what template the request relates. The template name can be included within the request (as a Microsoft-specific extension) or provided along with the request; CertEnroll and certreq.exe know how to do that.