Fix CERTSRV_E_TEMPLATE_CONFLICT (0X80094802) on Windows

You hit 0X80094802 and Windows says the request contains conflicting template information. Translation: somewhere in that request, two different certificate template names are fighting. That's it. One attribute says "use Template A" and another says "use Template B." The CA sees both, picks neither, and throws CERTSRV_E_TEMPLATE_CONFLICT.

I ran into this twice last quarter. Once it was a user editing a certreq INF file and leaving the old template line in. Once it was an MDM pushing a template name alongside one baked into a policy. Both times, the fix was quick once I knew where to look.

Here's the flow. Stop as soon as yours works.

Step 1 — The 30-second fix: kill the duplicate template line

If you're generating the request from a certreq INF file, open it and search for CertificateTemplate. You'll probably find it twice — one literal line and one under [RequestAttributes]. Delete the one that's wrong.

A clean INF should look like this:

[NewRequest]
Subject = "CN=server01.contoso.com"
MachineKeySet = True
Exportable = False
KeyLength = 2048
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC

[RequestAttributes]
CertificateTemplate = WebServer

If you see CertificateTemplate in both the [NewRequest] section and the [RequestAttributes] section, or twice inside [RequestAttributes] with different values, that's your conflict. Remove the one you don't want and re-run:

certreq -new request.inf request.req
certreq -submit -config "CA01\Contoso-CA" request.req request.cer

Nine times out of ten, this is the whole problem. Don't overthink it.

Step 2 — The 5-minute fix: check policies and MDM pushes

If the INF file is clean, something outside your request is adding a second template name. Common culprits:

• Group Policy — Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Certificate Enrollment Policy. If you've got an auto-enrollment policy pointing at template X and your request says Y, you get the conflict.
• Intune or other MDM — the SCEP or PKCS profile usually carries its own template name. If you also set it in the CSR template, they collide.
• Legacy scripts — old PowerShell that calls certreq -submit with a template flag while the INF already names one.

Check the request itself before you go hunting. Dump the attributes:

certreq -dump request.req request.txt

Open request.txt and search for "CertificateTemplate". You should see exactly one entry. If you see two, you've found the conflict source — it's being injected before the request even leaves the box.

For auto-enrollment, this event in Event Viewer is the tell:

Event ID 82 — CertificateServicesClient
Template conflict detected in auto-enrollment policy.

Kill the duplicate policy, run gpupdate /force, and retry enrollment. Don't skip the gpupdate — cached policy will bite you.

Step 3 — The 15-minute fix: when the template itself is broken

Sometimes the request is fine and the CA is the problem. Two scenarios:

Scenario A: The template is published twice with different names

Open certsrv.msc on the CA. Expand Certificate Templates. If you see the same template listed twice — say "WebServer" and "WebServer-2024" — and both are published to the same CA, an old client may be requesting one while the CA maps it to the other. Right-click the stale one and uncheck Publish certificate in Active Directory, then remove it from the CA:

certutil -SetCATemplates -WebServer

Or via GUI: Certification Authority > Certificate Templates > right-click the dup > Delete. Don't delete it from AD if other CAs use it — just unpublish from this CA.

Scenario B: Version conflicts from a failed template upgrade

If someone duplicated a v1 template into a v2, and both names got baked into enrollment policy, you'll hit 0X80094802 on every client. Check with:

certutil -CATemplates

You'll see something like:

WebServer: WebServer -- Auto-Enroll: Access is denied.
WebServer-New: WebServer-New -- Auto-Enroll: Access is denied.

Same template, two names. Unpublish the old one, force clients to refresh policy, and the conflict clears.

Real talk: if this is happening across a fleet, don't touch clients one at a time. Fix the CA first, then push certutil -pulse or gpupdate /force via your management tool. I've watched admins burn a day on a 20-machine rollout they could have fixed in 10 minutes.

Confirming it's actually fixed

After any fix, verify the request has a single template and the CA accepts it:

certreq -dump request.req request.txt
findstr /i "CertificateTemplate" request.txt
certreq -submit -config "CA01\Contoso-CA" request.req request.cer

You want one line for the template and no 0X80094802. If the cert lands, you're done. If you still see the error, something is injecting the attribute after you edit the file — check for wrapper scripts, MDM agents, or scheduled tasks that rewrite the INF before submission.

What doesn't help (skip these)

• Restarting the CA service. The conflict isn't a service problem. Waste of a maintenance window.
• Reissuing the CA cert. Nobody's root is broken here. Don't nuke your PKI over a template typo.
• Clearing the user's cert store. The conflict is in the request, not in stored certs. Doesn't help.
• Reinstalling the certificate services client. Not a client bug. Skip it.

The error code is specific. CERTSRV_E_TEMPLATE_CONFLICT means exactly one thing: two template names, one request. Find both, kill one, move on. I've seen people chase this for hours because the error message sounds vague. It isn't. Trust the code.