ADCS Certificate Enrollment with SAN Extensions

Modern browsers and clients reject certificates that only carry a Common Name, the Subject Alternative Name extension is no longer optional for TLS. That single fact pushes a lot of AD CS administrators toward exactly the enrollment mechanisms most likely to create a real security problem: enrollee-supplied subjects and CA-wide policy flags that make bulk SAN requests convenient at the cost of opening every template on the CA to the same risk. This is a guide to getting SAN enrollment right, the safe default, the legitimate cases for enrollee-supplied SAN, and precisely where usability and ESC1/ESC6-style risk actually trade off against each other.

For the deeper mechanics of why enrollee-supplied subjects need special handling generally, see ADCS SID Extension for Offline Certificate Requests, and for template permission hardening more broadly, see AD CS Template Hardening: ESC1-ESC16 Defense Playbook.

TL;DR: Key Takeaways

• The safe default is building SAN from Active Directory, not accepting it from the requester: a template configured to source the DNS name from AD attributes requires no risky flags and no enrollee-supplied subject at all.
• ESC1 and ESC6 are two distinct risks, not the same thing: ESC1 is a specific template misconfigured to allow enrollee-supplied subjects with a client authentication EKU and no approval. ESC6 is a CA-wide registry flag that exposes every template on the CA to enrollee-supplied SAN values, regardless of that template’s own settings.
• You almost never need the CA-wide flag: a certreq INF request with the SAN extension embedded directly in the CSR, submitted against one specifically scoped template, covers the legitimate bulk or multi-name SAN use cases without the CA-wide exposure EDITF_ATTRIBUTESUBJECTALTNAME2 introduces.
• Permissions are the actual control layer, not the extension itself: a properly restricted, approval-gated template with enrollee-supplied SAN is manageable risk. A broadly enrollable one is a privilege escalation path waiting to be found.
• Usability and risk trade off at a specific, identifiable point: automatic AD-driven SAN costs nothing in security and covers most domain-joined scenarios, anything beyond that needs a deliberate decision about scope, approval, and permissions, not a default toward convenience.

Why SAN Matters More Than It Used To

• Common Name-only certificates are effectively obsolete for TLS: modern browsers and most current client software require a Subject Alternative Name entry matching the hostname being connected to, a certificate relying on the Common Name alone will fail validation in current environments.
• This pushes more enrollment scenarios toward needing explicit SAN control: multi-hostname web servers, load-balanced farms presenting the same certificate under several names, and non-domain-joined servers all need a SAN that AD-driven automatic population may not fully cover, which is exactly where enrollee-supplied SAN starts looking attractive.

The Safe Default: Template-Driven SAN from Active Directory

• Configure the template to build the subject and SAN from Active Directory information, rather than accepting it from the request, this is the default, safest posture and covers the large majority of domain-joined web server and service certificate scenarios.
• Use the DNS name source tied to the requesting computer or service account, the CA determines the SAN value itself from an attribute it already trusts, rather than accepting whatever value a requester’s CSR happens to contain.
• Recognize what this approach cannot do, it doesn’t cover non-domain-joined servers, arbitrary additional hostnames not reflected in AD, or bulk multi-SAN certificates for a load-balanced farm, for those, you need one of the enrollee-supplied approaches below, deliberately and with appropriate controls.

When You Need Enrollee-Supplied SAN (and What That Actually Requires)

• Legitimate cases exist, and they’re common: a web server farm presenting several hostnames on one certificate, a non-domain-joined server with no AD attribute to source a DNS name from, or a SAN value that simply doesn’t correspond to anything in Active Directory.
• This requires a template configured with ENROLLEE_SUPPLIES_SUBJECT, which allows the requester to supply subject and SAN content directly in the certificate request rather than having the CA derive it.
• Understand plainly what this setting means from a security standpoint: a template with this flag set trusts whoever can enroll against it to supply an accurate subject and SAN, which is precisely the trust boundary ESC1 exploits when that template also carries a client authentication EKU and lacks manager approval, covered in depth below.

certreq INF Method for Explicit SAN Requests

• Build an INF file with the SAN extension embedded directly in the request, rather than supplied as a separate attribute at submission time, this is the more contained, template-scoped approach:

[NewRequest]
Subject = "CN=www.example.com"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=www.example.com&"
_continue_ = "dns=example.com&"
_continue_ = "dns=www2.example.com"

[RequestAttributes]
CertificateTemplate = WebServerSAN

• Generate the request with certreq -new, producing a CSR with the SAN entries baked directly into the request itself, then submit it to a CA against the specifically scoped template referenced in the INF.
• Keep the target template narrow and purpose-built, a template used specifically for this kind of request, rather than a general-purpose web server template, makes the permission and approval controls covered next much easier to reason about and audit.

Policy Controls: EDITF_ATTRIBUTESUBJECTALTNAME2 and Why It’s Different (and Riskier)

• Understand this is a CA-wide setting, not a template setting: certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 enables the CA to accept SAN values supplied as a request attribute at submission time, and it applies across every template that CA hosts, regardless of each template’s own configuration.
• This is the mechanism behind ESC6, once enabled, any authenticated requester who can enroll against any template on that CA, including templates that were never designed to allow subject control, can potentially supply an arbitrary SAN value, including one impersonating a different, more privileged identity.
• Microsoft documents this as a security risk directly, this isn’t an obscure interpretation, it’s acknowledged plainly in Microsoft’s own guidance, and it’s exactly the kind of setting that gets enabled once to solve one enrollment problem and then forgotten, quietly widening exposure across the entire CA indefinitely.
• Prefer the certreq INF method covered above in nearly every case, it achieves the same enrollment outcome, a certificate with the SAN entries you need, scoped to one specifically permissioned template rather than exposed CA-wide. If you find EDITF_ATTRIBUTESUBJECTALTNAME2 already enabled in your environment, treat that as a finding worth investigating and very likely disabling, not a standing configuration to leave alone.

Permissions: The Real Control Layer

• Restrict Enroll and Autoenroll permissions on any enrollee-supplied-subject template to a small, specifically trusted group, not Authenticated Users, not Domain Computers, a template that trusts the requester to supply its own subject shouldn’t be enrollable by everyone.
• Require CA manager approval on the Issuance Requirements tab for templates that accept enrollee-supplied subjects, this adds a human checkpoint between “someone requested a certificate with this SAN” and “the certificate was actually issued,” which closes most of the practical exploitation window.
• Never combine enrollee-supplied subject with a client authentication EKU and no approval, that specific combination is the textbook ESC1 pattern, and it’s worth an explicit check against every template in your environment, not just the ones you’re actively working on.
• Use the enrollment agent model for genuinely delegated, on-behalf-of scenarios, rather than granting broad enrollee-supplied-subject permissions directly, an enrollment agent workflow adds an additional layer of accountability for who requested a certificate on behalf of whom.

Common Security Mistakes (Balancing Usability vs Risk)

• Enabling EDITF_ATTRIBUTESUBJECTALTNAME2 to solve a single bulk-enrollment problem, the most common mistake in this entire area, a CA-wide flag enabled for one legitimate use case and then never revisited, silently exposing every other template on that CA indefinitely.
• Granting broad Enroll permissions on an enrollee-supplied-subject template with a client authentication EKU, this is ESC1 in its most direct form, and it’s frequently the result of copying an existing template without reviewing what its permissive settings actually enable.
• Skipping manager approval on templates that accept enrollee-supplied SAN “to keep enrollment fast”, the approval step is genuinely inconvenient for high-volume scenarios, which is exactly why it’s the control most often quietly removed, and exactly the control that matters most once it’s gone.
• Treating SAN enrollment as separate from your broader strong mapping and authentication posture, a SAN-bearing certificate used for domain authentication interacts with the strong certificate mapping requirements covered in our strong certificate mapping guide, don’t review these as unrelated topics.
• Never auditing who actually used a SAN-supplying template after it’s deployed, a template that was appropriately scoped at creation can drift in practice if nobody periodically reviews actual enrollment activity against it, pair the permission and approval controls above with a recurring review, not just an initial one.

How Encryption Consulting Can Help

Getting SAN enrollment right means balancing genuine operational needs, multi-hostname certificates, non-domain servers, bulk web server enrollment, against the exact misconfigurations that produce ESC1 and ESC6 exposure, and that balance is easy to get wrong under the pressure of “just make it work.”

Encryption Consulting’s PKI Services team supports this directly:

• Template design and review: building enrollee-supplied-subject templates with correctly scoped permissions, manager approval, and safe EKU combinations from the start, or auditing existing templates against these criteria.
• EDITF_ATTRIBUTESUBJECTALTNAME2 assessment: checking whether this flag is enabled in your environment, understanding why, and helping you migrate to the safer, template-scoped certreq INF approach where it’s currently relied on.
• ESC1/ESC6 exposure audits, systematically reviewing your CA and template configuration for these specific privilege escalation patterns, not just the SAN-specific ones covered here.
• Permission and enrollment agent design: building the right delegation model for bulk or on-behalf-of SAN certificate issuance, rather than defaulting to broad enrollment permissions for convenience.
• Ongoing enrollment activity review, helping you build recurring audits of who’s actually using enrollee-supplied-subject templates, so scope doesn’t quietly drift after initial deployment.

If you need SAN certificates issued at scale without opening ESC1 or ESC6-style exposure, our PKI Services team can design and audit this correctly.

Conclusion

SAN enrollment doesn’t have to be a tradeoff between usability and security, most scenarios are fully covered by template-driven, AD-sourced SAN with no risk at all. For the legitimate cases that need enrollee-supplied SAN, a certreq INF request against a narrowly scoped, permission-restricted, approval-gated template gets you there without the CA-wide exposure of EDITF_ATTRIBUTESUBJECTALTNAME2. Know the difference between ESC1’s template-level risk and ESC6’s CA-wide risk, and default toward the narrower, more auditable option every time convenience tempts you toward the broader one.

Related reading: AD CS Template Hardening: ESC1-ESC16 Defense Playbook · ADCS SID Extension for Offline Certificate Requests · Complete Guide to Strong Certificate Mapping Enforcement in ADCS · ADCS Basic Constraints Extension Explained · Education Center: Microsoft AD CS

Need SAN certificates issued at scale without the ESC1 or ESC6 exposure? Talk to our PKI Services team about designing safe enrollment templates. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What’s the safest way to include a SAN in an AD CS-issued certificate? Build the SAN automatically from Active Directory information on an online certificate template, using the DNS name source tied to the requesting computer or service account. This requires no risky policy flags and no enrollee-supplied subject, since the CA determines the SAN itself from a trusted, existing AD attribute.

What is the difference between ESC1 and ESC6 in the context of SAN enrollment? ESC1 is a template-level misconfiguration: a specific template allows the enrollee to supply the subject and SAN directly, combined with a client authentication EKU and no manager approval. ESC6 is a CA-wide setting, the EDITF_ATTRIBUTESUBJECTALTNAME2 registry flag, that allows enrollee-supplied SAN values across every template on that CA, regardless of each template’s own configuration.

Should EDITF_ATTRIBUTESUBJECTALTNAME2 be enabled to support bulk SAN certificate requests? Generally no. This flag applies CA-wide and affects every template on that CA, not just the one you’re trying to support, which is why Microsoft documents it as a security risk. A certreq INF request with the SAN extension embedded directly in the CSR, submitted against a specifically scoped, permission-restricted template, achieves the same enrollment outcome without the CA-wide exposure.

How do you request a certificate with multiple SAN entries using certreq? Build an INF file with a [NewRequest] section and an [Extensions] section specifying the Subject Alternative Name OID (2.5.29.17) with the DNS entries you need, then generate the request with certreq -new. This embeds the SAN values directly in the certificate signing request rather than relying on a CA-wide policy flag.

What permissions should be restricted on a template that allows enrollee-supplied SAN? Enroll and Autoenroll permissions should be limited to a small, specifically trusted group, not broad principals like Authenticated Users or Domain Computers. The template should also require CA manager approval, avoid combining enrollee-supplied subjects with a client authentication EKU, and be reviewed periodically for who has actually used it.