CERTSRV_E_PROPERTY_EMPTY 0X80094004: The Fix That Works

I know this error is infuriating. You're trying to enroll a certificate, everything looks fine, and then the CA spits out CERTSRV_E_PROPERTY_EMPTY (0X80094004). It's cryptic, it's vague, and it doesn't tell you which property is empty. I've seen this trip up admins on Server 2016, 2019, and even 2022. The good news? It's almost always one of three things, and all three are easy to fix once you know where to look.

This error happens on the Certification Authority (CA) side. The request reaches the CA, but when the CA tries to build the certificate, it finds a required property—usually the Subject name, sometimes a template attribute—missing or blank. The CA then refuses to issue. In my experience, the most common trigger is a certificate request that didn't include a Subject, often because the client application didn't populate it properly. But let's get into the fixes in order of how often I've seen them work.

Cause #1: The Certificate Request Has No Subject—Fix the Client Request

The most common cause is that the certificate request itself has an empty Subject. This happens more with web servers, network devices, or custom scripts that generate a CSR (Certificate Signing Request) without a Subject field. The CA template might be set to "Supply in the request," but the request didn't supply anything. The CA then throws 0X80094004 because the Subject property is empty.

I've seen this with older IIS servers, some Linux tools like openssl when people forget to specify -subj, and even with certain network appliances that generate their own CSRs. The fix is to make sure the CSR includes a Subject, even if it's just a common name.

If you're using OpenSSL, you'd do something like this (note the -subj flag):

openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr -subj "/CN=myserver.example.com"

If you're using a Windows client, like a web server, make sure the Common Name field is filled out in the certificate request wizard. In certreq, use an INF file with a proper Subject line:

[NewRequest]
Subject = "CN=myserver.example.com"
KeyLength = 2048
KeySpec = 1
RequestType = PKCS10
MachineKeySet = TRUE

Once you re-submit the request with a Subject populated, the CA should process it fine. This fix worked every time I've seen it in production.

Cause #2: Certificate Template Has a Blank Subject Name Setting

Second most common: the certificate template that you're using is misconfigured. Specifically, the template's Subject Name tab is set to "Build from this Active Directory information," but the field(s) it references are empty for the requesting user or computer. Or, the template is set to "Supply in the request," but the request doesn't include a Subject (which ties back to Cause #1).

Here's the scenario: You've got a web server template that's supposed to pull the server's FQDN from AD. But the computer object's dNSHostName attribute is blank—maybe it wasn't domain-joined properly, or the attribute got stripped. When the CA tries to build the Subject, it finds nothing, and you get 0X80094004.

To fix this, you need to check the template settings and the AD object. I'd suggest doing this in order:

1. Open the Certificate Templates console (certsrv.msc on the CA, then right-click Certificate Templates, Manage). Find the template you're using, right-click, Properties.
2. Go to the Subject Name tab. Look at what's selected. If it's "Build from this Active Directory information," note which fields are checked (usually Common name, DNS name, etc.).
3. Verify that the requesting computer or user actually has those attributes populated. For a computer, check dNSHostName and cn in AD Users and Computers. For a user, check displayName and userPrincipalName.
4. If the AD attributes are missing, fix them. You can do that with PowerShell:

Get-ADComputer -Identity "SERVER01" -Properties dNSHostName | Select dNSHostName
# if blank, set it:
Set-ADComputer -Identity "SERVER01" -DNSHostName "server01.example.com"

If you're using "Supply in the request," make sure you actually supply a Subject, like in Cause #1. Also, check the Request Handling tab—if "Allow private key to be exported" is checked, that's not related, but if "Renew with the same key" is checked, that might cause issues with certain requests. But the Subject Name tab is your main suspect.

Cause #3: Corrupted or Stale CA Database Entry

Third, and less common but still real, is a corrupted request entry in the CA database. Sometimes a request gets stuck in a weird state—maybe it was half-processed, or the database has a stale reference. This can cause the CA to think a property exists but then read it as empty.

I've seen this happen after a CA backup and restore, or when someone killed the Certificate Services service mid-request. The fix here is to either resubmit the request or, if that fails, restart the CA service and try again. If the problem persists, you might need to clean up the CA database.

First, try the easy route: restart the service and resubmit.

net stop certsvc
net start certsvc

If that doesn't work, you can check the CA database for pending requests that might be stuck. Use the CA admin console (right-click on the CA, Manage) and look at the Pending Requests folder. If there are requests there, deny or delete them. Then resubmit your request fresh.

In extreme cases, you might need to run certutil -cainfo to check for database issues, but that's rare. I wouldn't jump to that unless the service restart and request resubmission don't fix it.

A word of caution: if you have a lot of pending requests, don't delete them all blindly. Check the request ID and the requester first. But if the error is consistent, a clean slate often does the trick.

Quick-Reference Summary

That's it. In 90% of cases, you're looking at a missing Subject. In the other 10%, it's a template or a database hiccup. Fix the request first, then check the template, and only then touch the database. You'll have this resolved in under an hour—probably less.