CERTSRV_E_NO_REQUEST (0X80094002) Fix

Cause 1: The request never reached the CA — it was lost or rejected silently

This is the most common scenario. You submit a certificate request (via certreq, MMC, or web enrollment), and the CA either failed to process it or rejected it without logging it. The culprit here is almost always a permissions issue on the CA server itself. The requesting user or computer lacks the Enroll permission on the certificate template, or the CA is configured to only accept requests from specific security groups.

The fix is dead simple:

1. Open the Certification Authority snap-in (certsrv.msc).
2. Right-click the CA name, go to Properties.
3. Check the Security tab. Make sure the requesting user or computer has Enroll and Read permissions.
4. Also check the template permissions. Run certtmpl.msc, find the template, and verify the same user/computer has Enroll rights.

If permissions look fine, the next likely cause is the request timing out. Windows CA has a default pending request timeout of 1 hour. If the client took too long to submit, the CA already cleared it. You'll need to resubmit the request.

Cause 2: The request ID from the client doesn't match the CA's pending request

This one's trickier. When you use certreq with a request file, the CA assigns a request ID. If you somehow lose that ID or use a different one, you get 0x80094002. This happens a lot in automated scripting where the script grabs the wrong ID from an outdated file.

To check this:

1. On the CA server, open the Certification Authority MMC.
2. Go to Pending Requests folder. Look for any requests from the same client. Note their request IDs.
3. Compare that ID with what the client is using. You can see the client's request ID in the certreq output file or in the event logs.

If the IDs don't match, you have two options:

• Reissue the request with the correct ID. On the client, run certreq -retrieve <correctID> output.cer
• Or just resubmit the entire request from scratch. Delete the old .req file, generate a new one, and submit it again.

I've seen this happen when a server reboots mid-request. The pending request survives, but the client's local state (like the request file) gets stale. Always delete old .req files before retrying.

Cause 3: The CA database is corrupted or has a bad index

Rare, but real. If the CA has thousands of pending requests and the database index gets corrupted, it can't find a request that's actually there. You'll see this error even though the request shows up in the MMC. Check the Application event log for ESENT warnings (source: ESE, event IDs 474 or 479). These point to Jet database corruption.

Fix it with:

certutil -databaserepair

Run this on the CA server while the service is stopped:

net stop certsvc
certutil -databaserepair
net start certsvc

If the repair fails, restore the CA from backup or rebuild it. But honestly, this only happens if the CA has been running for years without maintenance or after a disk failure. If you're running Server 2012 or older, upgrade. Those old ESENT versions were fragile.

Quick-Reference Fix Table

Bottom line: 90% of the time it's permissions or a stale request file. Don't waste time rebuilding the CA until you've verified both of those. And for the love of all that is holy, back up your CA database regularly. You should have a backup from today if you're running production AD CS.