CERTSRV_E_SIGNATURE_REJECTED 0x8009480B: Fix Required Policy Errors

You're submitting a cert request and the CA spits back 0x8009480B — CERTSRV_E_SIGNATURE_REJECTED. The full text is usually: "One or more signatures did not include the required application or issuance policies. The request is missing one or more required valid signatures."

Here's the thing most people miss: the signature itself is fine. Crypto-wise, nothing's broken. What the CA policy module is saying is the envelope around that signature doesn't carry the policy OIDs the template told the CA to demand. It's a policy check, not a crypto check. Once you get that, the fix gets a lot less scary.

Common trigger I see: someone clones an existing template, adds a custom application policy OID (say for smart card logon or a third-party VPN client), then tries to enroll from a machine that's using the old request path — certreq with a legacy INF, or a GPO autoenrollment that hasn't refreshed. The template now has pkipolicy populated, the request doesn't, and the CA rejects it. Every time.

Work through this in order. Stop as soon as your request goes through.

Step 1: The 30-second fix — check the template's policy settings

Nine times out of ten, this is a misconfigured template, not a broken CA. Open certtmpl.msc on a machine with RSAT (or on the CA itself), find the template you're enrolling against, right-click, Properties.

Go to the Extensions tab. Highlight Issuance Policies and Application Policies. Look at the right pane.

• If Application Policies lists a specific OID (something other than "All"), the CA will require that OID to appear in the request signature.
• If Issuance Policies has anything other than "All Issuance Policies" or is empty, same deal.

If you don't actually need that custom policy, right-click each one → Remove, or set Issuance Policies to "All Issuance Policies." Then bump the template version and let AD replicate. Reissue the request.

If you do need the custom policy, don't remove it — jump to Step 3. Removing it just to make the error go away means you're shipping certs that aren't actually valid for the intended use case, and the application that consumes them will reject them later. That's a worse problem to debug at 2am.

Step 2: The 5-minute fix — force the correct request path

If the template is right and you still get 0x8009480B, the request being submitted doesn't match what the template expects. This almost always means one of these:

1. You're submitting with certreq -submit against a saved .req that was generated before the template change.
2. You're using an old INF that doesn't reference the template by name.
3. Autoenrollment is using a cached template definition.

Regenerate the request against the current template:

certreq -new myrequest.inf myrequest.req
certreq -submit -config "CA01.contoso.com\Contoso-Issuing-CA" myrequest.req mycert.cer
certreq -accept mycert.cer

Make sure the INF's [NewRequest] section references the template correctly. It should look like this:

[NewRequest]
Subject = "CN=user01.contoso.com"
MachineKeySet = FALSE
ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
KeyAlgorithm = RSA
KeyLength = 2048
CertificateTemplate = UserSmartCardLogon

For autoenrollment, run gpupdate /force on the client, then check certlm.msc → Personal → Certificates → right-click → All Tasks → Request New Certificate. Walk through the wizard and pick the template manually. If that works but autoenroll doesn't, your GPO is pointing at the wrong template or the CA isn't publishing it.

Quick sanity check on publishing:

certutil -CATemplates | findstr /i "YourTemplateName"

If it's not in that list, the template isn't published on the CA and no amount of client fiddling will fix it. Publish it from certsrv.msc → Certificate Templates → New → Certificate Template to Issue.

Step 3: The 15-minute fix — add the required policy to the request

Now we're at the real fix for the cases where the policy has to be there. You've got a custom application policy OID on the template that legitimately must appear in the request. You need to embed it in the signature. certreq won't do this cleanly from a plain INF — you need to inject the CertificatePolicies extension manually.

Grab the OID from the template's Extensions tab first. It's usually a dotted string like 1.3.6.1.4.1.311.20.2.2 (Smart Card Logon) or your vendor's custom one.

Add an [Extensions] section to your INF:

[Extensions]
2.5.29.32 = "{text}2.5.29.32"

[2.5.29.32]
_continue_ = "1.3.6.1.4.1.311.20.2.2"
_continue_ = "1.3.6.1.5.5.7.3.2"

The OID 2.5.29.32 is CertificatePolicies. Every OID you list under it gets baked into the signed request. Submit again with certreq -submit and it should sail through.

If you're using C# or PowerShell to build the request via the CX509CertificateRequestPkcs10 COM object, the property is CertificatePolicies on the request object. Set it before calling Encode(). If you set it after, the signature won't cover it and you're back to 0x8009480B.

Step 4: When the CA itself has been told to require it

Occasionally the requirement isn't on the template at all — it's baked into the CA's policy module via a custom policy DLL, or set with certutil on the CA. Check with:

certutil -getreg policy\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\
certutil -getreg policy\ApplicationPolicies

If you see OIDs listed under ApplicationPolicies that you didn't put there, that's your smoking gun. Either a previous admin added them for a specific use case, or a vendor's CA plugin did. Don't just delete them blind — those exist to constrain what the CA will issue. Confirm with your security team what's expected, then remove only what's stale, and only on a CA you can restart during a maintenance window.

Blunt note: don't run certutil -setreg casually on a production issuing CA. If you break the policy module, the CA stops issuing for everyone, not just you. Take a registry export first. I've watched someone wipe out a root CA's policy config chasing a client-side error that had nothing to do with it.

Quick reference

One more thing — if the client machine is joined to a different forest than the CA, cross-forest enrollment needs the template's policies to be readable by the client. If the client can't read the template's pKICertificateTemplate object, it can't know what policies to include. Check the template's security ACL if you're in a multi-forest setup. That's the one case where the error is genuinely a permissions problem, not a config problem.