You try to renew a cert and the CA spits out 0x8009400E — CERTSRV_E_BAD_RENEWAL_CERT_ATTRIBUTE — and suddenly your renewal pipeline is dead in the water. Annoying, but it's almost always fixable in about ten minutes once you know what the CA is actually complaining about.
The fix
That error means the CA read the RenewalCertificate attribute on your request and decided it doesn't match a certificate it's willing to renew. The certificate referenced either isn't in the CA database, wasn't issued by this CA, is revoked, has already been superseded, or your request is pointing at the wrong cert entirely. Fix the reference, and the error goes away.
1. Figure out what the request is actually referencing
If you're using certreq, dump the request and look at the renewal attribute:
certreq -dump request.req dump.txtOpen dump.txt and search for 1.3.6.1.4.1.311.21.1. That OID is the RenewalCertificate attribute. What follows is the serial number and issuer of the cert you're claiming to renew. Cross-check that against the actual cert you hold:
certutil -dump oldcert.cerNine times out of ten the serial in the request doesn't match the cert file in your hand. Somebody copied the wrong .req into the pipeline, or an automated renewal script cached an old serial.
2. Regenerate the request properly
Don't hand-edit the attribute. Rebuild the request from the actual certificate you want renewed using the INF approach:
[NewRequest]
Subject = "CN=server01.contoso.com"
RenewalCert = 7f 3a 11 22 ...
MachineKeySet = TRUE
ProviderName = "Microsoft Software Key Storage Provider"Then submit:
certreq -new renew.inf renew.req
certreq -submit -config "ca01.contoso.com\Contoso-Issuing-CA" renew.req renew.cerThe RenewalCert value must be the SHA1 thumbprint of the cert you're renewing, as raw hex bytes, no spaces if you're pasting from a script. If you paste the wrong thumbprint, you're right back to 0x8009400E.
3. Verify the cert exists in the CA database
If the request looks right but the CA still rejects it, the cert might not be in the CA's database at all. This happens after a CA restore from backup, or when you're renewing a cert issued by a different CA in the same hierarchy. Check:
certutil -config "ca01.contoso.com\Contoso-Issuing-CA" -view -restrict "SerialNumber=7f3a1122" -out "RequestID,SerialNumber,Disposition"If nothing comes back, that CA never issued that cert, and it has every right to reject your renewal. You need to request a new cert instead of renewing.
Why this works
The CA doesn't trust your request. It trusts its own database. When it sees a renewal request, it looks up the referenced serial, checks that the cert was issued by this CA, checks it's not revoked, checks the template is still valid for renewal, and only then does it consider honoring the request. If any of those checks fail, you get 0x8009400E — a deliberately vague "that renewal attribute is bad" rather than telling you which specific check failed.
Rebuilding the request with the correct RenewalCert value lines everything up. The CA can now find its own record, confirm the cert is renewable, and issue a new one chained to the old.
Had a client last month — a mid-size MSP in Ohio — whose nightly renewal script started failing on 40 servers simultaneously after a CA migration. Turned out the script was reading the serial from a stale inventory DB that still pointed at certs issued by the retired old CA. Updating the inventory lookup fixed all 40 in one deploy.
Less common variations
Template no longer allows renewal
If someone edited the certificate template and unchecked "Allow private key to be re-used" or removed the template from the CA's issuance list, renewal fails with the same error. Check the template's Renewal settings in certtmpl.msc, and verify the template is still issued by the CA in certsrv.msc.
Cert is already superseded
A cert that's already been renewed once won't renew again from the same serial. Windows shows this as the old cert sitting in "Superseded Certificates" in the Certificates MMC. You need to renew from the newest cert in the chain, not the original.
Cross-CA renewal
Renewing across CAs (old CA decommissioned, new CA in place) always fails with 0x8009400E. There's no way around it — the new CA has no record of the old cert. Request a fresh cert through the normal enrollment flow. If you need continuity, do a CA migration properly using certutil -backup on the old CA before decommissioning.
Key storage provider mismatch
If the original cert lives in a legacy CSP (Microsoft Enhanced Cryptographic Provider) and your renewal request uses the new KSP, the CA can reject the attribute. Match providers, or migrate the key first with certutil -key -csp.
Request is missing the attribute entirely
Some tools strip unknown attributes when they round-trip a request through a bad parser. If the RenewalCertificate OID isn't in the dump at all, the CA either treats it as a new request (fine) or rejects it outright depending on template settings. When in doubt, regenerate from scratch.
Prevention
A few habits save you from seeing 0x8009400E again:
- Store cert serials and thumbprints in the same DB that drives your renewal scripts. If inventory says a cert exists, the cert must exist there.
- Never copy renewal requests by hand between machines. Regenerate them from the source cert on the machine that holds the key.
- Before a CA migration, run
certutil -backupand migrate the database. Skipping this is what caused the MSP mess above. - Monitor cert expiration 60+ days out, not 7. Renewal churn at the deadline is when wrong serials sneak in.
- Set renewal on the template side for machine certs (
AutoEnrollment), which sidesteps the whole manual renewal attribute problem.
If you're still stuck after all that, run the request through certutil -v -submit to get verbose output — it usually names the exact check that failed. Then look at the CA's event log on the CA server itself. The Application log under source CertificationAuthority will tell you what the CA thought was wrong, which the client-side error never does.