第 3 章，共 8 章
The object that decides who may enrol, what the subject may contain, and what the certificate can do.
约 13 分钟阅读
An enterprise CA cannot issue arbitrary certificates. Every certificate is based on a template, and the template decides almost everything: who may request it, what goes into the subject, which key usages apply, how long the certificate lasts and whether an administrator must approve it.
| Permission | Allows | Risk if too broad |
|---|---|---|
| Read | See the template exists and its settings | Low, but enables discovery of weak templates |
| Enroll | Request a certificate from the template | Direct: the requester gets a certificate |
| Autoenroll | Receive certificates automatically by policy | Silent issuance at scale after a template change |
| Write / Full Control | Modify the template itself | Severe: can convert a safe template into an abusable one |
Write access to a template object is one of the most valuable permissions in an AD environment, because it lets an attacker change the rules rather than find a way around them. This is the condition behind ESC4.
| Setting | Safe choice | Why |
|---|---|---|
| Subject name source | Built from AD information | Prevents a requester choosing another identity |
| Supply in the request | Disabled | The core condition behind ESC1 |
| Extended Key Usage | Exactly what is needed | Client Authentication on a broad template creates credentials |
| Any Purpose / no EKU | Avoid | Turns a convenience template into a wildcard |
| Manager approval | Enabled for sensitive templates | Turns issuance into an explicit decision |
| Enrolment agent | Restricted to dedicated accounts | Otherwise anyone can request on behalf of anyone |
| Key archival | Only for encryption templates | Archived signing keys are a liability |
| Validity period | Short for TLS, longer only with justification | Bounds the lifetime of a leaked key |
List published templates
Unpublished templates cannot be requested, which is a cheap way to reduce surface.
Map effective permissions
Include nested groups; an apparently narrow ACL can still include Everyone through a group chain.
Check subject behaviour
Is the subject built from AD, or supplied by the requester?
Check EKU and application policies
Does this certificate authenticate, sign code, or only encrypt?
Check approval and validity
Are sensitive requests reviewed, and is the lifetime proportionate?
Record the decision
Note owner, justification and review date, so the next person understands the intent.
It lets the requester put any name in the subject or SAN, so with an authentication EKU the certificate can represent another identity.
Any user can change the template into an unsafe one — the ESC4 pattern.