Fix CERTSRV_E_DOWNLEVEL_DC_SSL_OR_UPGRADE (0X80094013)

You hit the 0x80094013 wall

That error code — 0x80094013 with the message CERTSRV_E_DOWNLEVEL_DC_SSL_OR_UPGRADE — usually shows up when you're trying to enroll a certificate on a domain controller that's running Windows Server 2012 R2 or earlier, and the environment has a newer Certificate Authority. It's a pain because it stops the DC from getting its required certificate, which can break LDAPS or Kerberos. Let's get it fixed.

The real fix: Enable HTTPS on the CA's web enrollment role

Here's the core issue — the downlevel DC needs to talk to the Certificate Enrollment Web Service (CES) or the Certificate Enrollment Policy Web Service (CEP) over HTTPS. If the IIS site hosting those services doesn't have a valid SSL binding, the DC throws 0x80094013. The fix is to make sure that IIS binding exists and is using a certificate the DC trusts.

1. Log into your Certificate Authority server (the one running AD CS).
2. Open IIS Manager — search for "inetmgr" in Start.
3. In the left Connections pane, expand your server, then expand Sites.
4. Click on the site that hosts your CEP or CES — likely named Default Web Site or something like CertSrv.
5. In the middle pane, double-click Bindings.
6. You should see an entry for https port 443. If you don't, click Add.
7. Set Type to https. Port stays 443. In the SSL certificate dropdown, pick a certificate that matches the CA server's name (typically the one issued by your CA itself).
8. Click OK, then close the Bindings window.
9. Now restart the IIS service: open an admin Command Prompt and type iisreset. After a few seconds, you'll see "Internet services successfully restarted".

After this step: Try the certificate enrollment again from the downlevel DC. If it works, you're done. But sometimes the error persists. That's when you move to the next step.

If it still fails: Install the hotfix or registry workaround

On the downlevel DC itself (the one that generated the error), you might need a specific update. For Windows Server 2012 R2, the hotfix is KB3098624. For Server 2008 R2, it's KB3098623. Install the right one and reboot.

Can't install hotfixes? There's a registry workaround that does the same thing:

1. On the downlevel DC, open Regedit as Administrator.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
3. Right-click in the right pane, choose New → DWORD (32-bit) Value.
4. Name it DownlevelDCSSL.
5. Double-click it, set the value to 1, and click OK.
6. Close Regedit and reboot the DC.

What should happen now: After the reboot, the certificate enrollment request should succeed. The registry key tells the Certificate Service to accept HTTPS connections from downlevel DCs without requiring the full IIS binding — it's a crutch, but it works.

Why does this error happen?

Short answer: Microsoft changed how certificate enrollment works starting with Windows Server 2012. Newer CAs expect downlevel DCs to use HTTPS for enrolling certificates, but those older DCs don't always support the protocol the CA expects. The error code literally means "downlevel DC requires SSL or upgrade." It's Microsoft's way of saying your old DC needs to either get a hotfix or be upgraded to a newer OS.

The real-world trigger? You just added a new CA to your domain, or you upgraded your existing CA to Server 2016 or later, and suddenly your older DCs can't get certificates. I've seen this most often in hybrid environments where someone stood up a new CA without checking the IIS bindings.

Less common variations that fool people

Sometimes the issue isn't the IIS binding at all. Here's what else I've run into:

• Certificate chain issue: The SSL certificate on the CA's IIS site might not have its full chain installed. Check the certificate with certlm.msc on the CA. If the chain shows a red X, re-import the intermediate CA cert.
• DNS name mismatch: The downlevel DC resolves the CA's hostname to an IP that doesn't match the certificate's subject name. Run nslookup [CA-server-name] from the problem DC. If it returns a different IP, fix DNS.
• Firewall blocking port 443: Sounds basic, but I've spent hours on this. Telnet to port 443 from the downlevel DC: telnet [CA-server-name] 443. If it fails, check Windows Firewall or any hardware firewall between them.
• Multiple CA roles on one server: If you installed both the CA role and the Web Enrollment role on the same box, the IIS site might be using HTTP (port 80) instead of HTTPS. Revisit the bindings step above.

Prevention: Keep your DCs updated and plan ahead

The easiest way to avoid this error in the future: keep your domain controllers patched. That means at least Windows Server 2012 R2 with all current updates, but ideally Server 2016 or later. If you're planning a new CA deployment, do these things:

• Before you stand up the CA, verify that all DCs can communicate over HTTPS to the server where the CEP/CES roles will live.
• Install the CEP and CES roles on a separate box if possible — it keeps the IIS configuration cleaner.
• Check the IIS binding immediately after installing the Web Enrollment role. Don't assume it's set up right.
• After any CA upgrade, run a test certificate enrollment from every DC version in your environment.

One more thing — if you're running a mixed OS environment (Server 2008 R2 and Server 2019 together), the registry workaround is your friend until you can retire those old boxes. But don't leave it as a permanent fix; it's a band-aid.

"I've seen the registry key fix save a weekend migration. But I've also seen it cause weird issues later if you forget it's there. Document it." — Me, after doing this for 15 years.