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
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.