0X8009400D

Fix CERTSRV_E_NO_CAADMIN_DEFINED (0X8009400D) Fast

Cybersecurity & Malware Intermediate 👁 11 views 📅 Jun 19, 2026

This error means no one has permission to manage the CA. You'll fix it by adding yourself as a CA administrator. It takes 30 seconds if you have access.

What's the 0x8009400D Error Telling You?

This error shows up when you try to manage an Active Directory Certificate Services (ADCS) enterprise CA, usually right after you install it or restore it from backup. The message says "At least one security principal must have the permission to manage this CA."

What it actually means: the CA's security descriptor is empty. Nobody has the Manage CA permission. That includes the built-in Administrator, Domain Admins, and even the account that installed the service. This happens more often than you'd think—especially on Server 2016 and Server 2019 builds where the installer doesn't always propagate permissions correctly.

You'll see this error when you open the Certification Authority snap-in and try to right-click the CA name, or when you run certutil -config <CA> -ping. The snap-in won't even load the CA tree.

Fix 1: Give Yourself the Manage CA Permission (30 seconds)

This is the fix that works 90% of the time. You need to be running the MMC as a domain admin or local admin on the CA server. Here's what to do:

  1. Open the Certification Authority snap-in. Press Win + R, type certsrv.msc, and hit Enter. If the snap-in loads with the error, that's fine—you can still get to the properties.
  2. Right-click the CA name (it's at the top of the left-hand tree) and select Properties.
  3. Click the Security tab. You'll see a list of groups and permissions. If the list is empty, that's your problem.
  4. Click Add. Type your domain username (like YOURDOMAIN\YourName) and click Check Names to validate it. Click OK.
  5. In the Permissions list at the bottom, check Allow next to Manage CA.
  6. Click Apply then OK. You should now see the CA tree populate. If it doesn't, close and reopen the snap-in.

After you click Apply and OK, close the snap-in and reopen it. The error should be gone. You'll see the CA name, the issued certificates folder, and everything else.

Fix 2: Use certutil to Grant Permissions (5 minutes)

If the Security tab is grayed out or you can't open Properties at all, certutil is your next move. This command-line tool can force-write the security descriptor.

Open an elevated command prompt (right-click Command Prompt, select Run as Administrator). Run this command, replacing YourDomain\YourName with your actual account:

certutil -setreg CA\SecurityDescriptor "D:PAI(A;OICI;0x1F;;;DA)(A;OICI;0x1F;;;SY)(A;OICI;0x100;;;NS)(A;CI;0x1F;;;YourDomain\YourName)"

What this does: It sets a security descriptor that gives Manage CA permission to Domain Admins (DA), SYSTEM (SY), Network Service (NS), and your specific account. The 0x1F is the hex mask for full control. The ;OICI; applies the ACE to the CA object and its subobjects.

After you run the command, you'll see CertUtil: -setreg command completed successfully.

Restart the CA service for the change to take effect:

net stop certsvc && net start certsvc

Now open certsrv.msc. The error should be gone. If it's not, double-check the command syntax—one missing character will fail silently.

Fix 3: Repair the CA Security Descriptor with PowerShell (15+ minutes)

This one's for when the registry fix above doesn't stick, or you're dealing with a CA that was restored from backup and the SD is completely corrupt. You'll need the ADCS Administration module on a Windows Server 2016 or later.

First, check if the module is installed:

Get-Module -ListAvailable -Name ADCSAdministration

If it's not there, install the ADCS tools:

Install-WindowsFeature -Name ADCS-Administration -IncludeManagementTools

Now open PowerShell as Administrator. Get the CA object:

Import-Module ADCSAdministration
$CA = Get-CACrlDistributionPoint

That will already throw an error if the SD is empty. Instead, directly set the security descriptor using the Set-CAProperty cmdlet:

$SD = New-Object System.Security.AccessControl.CommonSecurityDescriptor($true, $false, "D:PAI(A;OICI;0x1F;;;DA)(A;OICI;0x1F;;;SY)")
Set-CAProperty -Property SecurityDescriptor -Value $SD

That sets it for Domain Admins and SYSTEM. If you want your specific account added, include it in the SDDL string like in Fix 2. After running Set-CAProperty, restart the CA service:

Restart-Service -Name CertSvc -Force

Test by running certutil -config <YourCA> -ping. It should return CertUtil: -ping command completed successfully.

What If None of These Work?

You might be dealing with a CA whose database is corrupted or whose registry key for the security descriptor is missing entirely. Open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAName>.

If the SecurityDescriptor value is missing or blank, you've got a bigger problem. Do not delete the CA database yet. Instead, back up the registry key, then create a new REG_BINARY value named SecurityDescriptor and paste in a known-good SD from a working CA. Export the SD from a working CA using:

certutil -getreg CA\SecurityDescriptor

That outputs a hex string. Copy that string and write it to the broken CA. Then restart the service.

I've seen this exact scenario on Server 2016 after a failed upgrade. The registry entry was there but empty—zero bytes. Rewriting it fixed everything in under 10 minutes.

One Last Thing

After you fix the error, immediately add at least two CA administrators. I always add the built-in Domain Admins group and a specific service account. If the only admin is your personal account and you get locked out, you're back to square one. And that's a pain when you're remote.

Test the fix by requesting a test certificate:

certreq -new -q

If it completes, you're golden.

Was this solution helpful?