ASD ISM 1948 Certificate manager approval for templates allowing supplied SANs
What it says
Certificate manager approval is required for certificate templates that allow a Subject Alternative Name to be supplied.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAny certificate template that lets a requester supply their own Subject Alternative Name must be gated so a certificate manager approves each request before a certificate is issued.
A certificate template is the recipe a certificate authority (CA) uses to decide what a certificate will contain and who can ask for one. Normally the CA fills in the identity of the certificate (the names it is valid for) from the directory, so a requester cannot choose it. Some templates, however, allow the requester to supply a Subject Alternative Name (SAN) in the request itself. A SAN is the list of extra names, such as host names or user identifiers, that the certificate is also valid for. This control says that where a template allows a SAN to be supplied by the requester, the CA must not issue the certificate automatically. Instead, the request must wait for a certificate manager (a person holding the CA's certificate manager role) to review and approve it. Why it matters: if a requester can write their own SAN into a certificate and the CA issues it with no human check, they can obtain a certificate that claims to be a different server or a different user. In environments that use certificates for authentication, that is a direct route to impersonating a privileged account or a trusted service. Requiring a certificate manager to approve every such request puts a person between the requester and the issued certificate, so an attacker who has enrolment rights on the template still cannot mint a certificate for an identity they do not own.
Free. Save your status, tasks and notes.
Why it matters
Without certificate manager approval, anyone permitted to enrol against a template that accepts a supplied SAN can request a certificate naming an identity they do not control, and the CA will issue it automatically. The resulting certificate can be used to impersonate a service or authenticate as another user, including highly privileged accounts, giving an attacker a persistent, hard-to-detect path to escalate privilege or intercept traffic. Because the certificate is legitimately issued by the organisation's own CA, other systems will trust it until it is discovered and revoked.
How to implement
The PKI administrator inventories every published certificate template and identifies those that allow a SAN to be supplied in the request, including templates where the subject is built from the request and any CA-level setting that honours SAN attributes in requests, and records the list.
The PKI administrator configures each identified template so that issuance requires certificate manager approval (for example, setting the template's issuance requirement to 'CA certificate manager approval'), so requests land in a pending state instead of being issued automatically.
The PKI owner assigns the certificate manager role on the CA to a small, named group of staff, removes it from anyone else, and documents who holds it and how requests reach them.
The certificate manager team writes a short approval procedure covering how to confirm the requester is entitled to the supplied SAN (for example, checking ownership of the host name or the user identifier against an authoritative source) and how to record the decision on each request.
The PKI administrator adds the approval setting to the template change process, so that any new template or any change to an existing template that permits a supplied SAN is checked for the approval requirement before it is published to a CA.
Keep it running
Day to day, this control lives in two places: the configuration of each certificate template, and the working routine of the people who hold the certificate manager role.
On the template side, every template that allows the requester to supply a SAN (for example, templates configured so the subject name is supplied in the request, or CAs with a flag that honours SAN attributes in requests) needs its issuance setting changed so requests go to a pending state and require certificate manager approval rather than auto-enrolling. New templates should be checked for this setting before they are published to a CA, and template changes should be reviewed so that approval is not silently switched off.
On the people side, certificate managers need a way to see pending requests promptly, a documented basis for deciding whether the SAN a requester has supplied is one they are entitled to, and a habit of recording why each request was approved or denied. Pending queues should be checked regularly so that legitimate requests are not left waiting, which is what usually tempts teams to disable the approval requirement.
Periodically, someone should reconcile the list of templates that permit a supplied SAN against the list of templates that require approval, and confirm the two match. The same review should confirm that the certificate manager role is held only by the intended staff.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current list of certificate templates published to each CA, with the setting that shows whether a SAN can be supplied in the request.
Look at
Identify every template where the requester can supply a SAN, and note whether each one is configured to require certificate manager approval before issuance.
Good evidence
Every template that permits a supplied SAN has certificate manager approval switched on, and the organisation can explain how that list was compiled.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export or screenshot of the issuance settings for each template that allows a supplied SAN.
Look at
Check that the issuance requirement is set to certificate manager approval rather than auto-enrolment, and that no template on the list has the setting turned off.
Good evidence
The configuration itself, not just a policy statement, shows approval is required on each of those templates.
- Check 3 of 5What an auditor asks for
Ask for
Ask who holds the certificate manager role on each CA and how that membership is maintained.
Look at
Compare the role membership against the documented list of intended approvers and look for generic, shared or service accounts.
Good evidence
A small, named group of staff holds the role, the membership matches the documented list, and there is a record of when it was last reviewed.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the CA's record of issued and pending certificate requests for a recent period, filtered to templates that allow a supplied SAN.
Look at
For a sample of issued certificates, check that each request went through a pending state and was approved by a certificate manager before issuance.
Good evidence
Every sampled certificate from those templates shows an approval by a named certificate manager, with no automatic issuance.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the procedure certificate managers follow when approving a request that includes a supplied SAN.
Look at
Check that it describes how the approver confirms the requester is entitled to the names in the SAN and how the decision is recorded, and see whether recent approvals show that check being done.
Good evidence
The procedure exists, approvers can describe it, and approval records show the entitlement check was performed rather than requests being approved on sight.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1948 requires certificate manager approval for certificate templates that allow a requester-supplied SAN, constraining how certificates (and thus authentication/identity assertions) can be issued. Annex A 5.15 requires organisations to establish and implement access control policies and procedures based on business and security requirements, which can include controls over certificate-based access and identity assertions. ISM-1948 is a specific access/identity control within the broader policy and procedure requirements of Annex A 5.15.
This control partially meets A.8.32.
ISM-1948 requires CA Certificate Manager approval before using AD CS certificate templates that permit requester-supplied Subject Alternative Names (SANs). Annex A 8.32 requires that changes to information systems (including configuration of identity and PKI components) follow formal change management procedures. ISM-1948 is a specific, security-critical approval gate for one AD CS configuration risk, whereas Annex A 8.32 is broader and covers change control across all systems and changes.
This control supports A.8.2.
ISM-1948 requires CA Certificate Manager approval before enabling certificate templates that let requesters supply SANs, limiting a common path to certificate abuse and privilege escalation. Annex A 8.2 requires privileged access rights to be restricted and managed, which includes administrative capabilities over AD CS, certificate template publishing, and enrolment permissions. ISM-1948 provides a concrete administrative control point that helps manage privileged actions in the PKI/AD CS domain, but Annex A 8.2 is broader and not specific to certificates or SAN handling.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.