Installing AD DS Certificates (in NTDS\Personal) on Server 2012 R2 Core

  • Last Post 19 November 2015
chaselton posted this 19 November 2015

I’m currently testing out Server 2012 R2 Core in our alpha forest and I’ve run into an interesting problem:  I can’t seem to install certificates in the NTDS\Personal store.  This is mandatory for our production environment because we’re using an alternate LDAPS connection FQDN because of deprecated support for .local domains.   Using an MMC, loaded with the Certificates snap-in, from a 2008 R2 DC doesn’t work and PowerShell v4 cert: drive and cmdlets only allow access to the CurrentUser and LocalMachine stores. I’m currently looking at certutil to see if there’s an option to allow installation in the NTDS\Personal store.   I could just re-load the GUI every time I need to install/renew a cert and unload it after, but combining the time it takes to do that with the number of domain controllers adds up.   Has anyone else run into this issue?

Order By: Standard | Newest | Votes
kevinrjames posted this 19 November 2015

Should work. Need to add from the service account (Active Directory Domain Services) then NTDS/Personal   /kj 


Tony posted this 19 November 2015

Hi Cynthia


There doesn't appear to be an obvious way to achieve what you want with either Powershell or certutil.

Powershell script to Install Certificate in Active ...

Hi Everybody! I'm trying to write a powershell script to install a certificate into the active directory certificate store, Here are the steps to do this manually ...



I think re-loading the GUI temporarily might be your best option at this stage.



hcoleman posted this 19 November 2015

Yes. I ended up opening a case with Microsoft, and here is what they came back with:


“1. Import the PKCS #12 containing the shared certificate and private key into the Local Computer Personal store:


certutil -importpfx CertAndKey.PFX.


You must import the certificate and private key on the DC first. We'll be changing the location in which the certificate itself is stored, but we won't be changing the location of the private key, nor will we need to modify the property

of the certificate itself that points to the private key.


2. Enumerate the store Local Computer Personal Store filtering on the subject name of the certificate Subject common name:


certutil -store my


Make note of the certificate thumbprint. In this example: 9540fd706b336dbd58dfa133f0a7a5e369b83b0a.


3. This certificate is going to be stored in the following location in the registry:




4. Export that key to a file:


reg export HKLM\SOFTWARE\Microsoft\SystemCertificates\My\Certificates\9540fd706b336dbd58dfa133f0a7a5e369b83b0a SecureLDAP.reg


5. Now edit that file:


We're going to modify the registry path, and change this:




to this:




The above path is the registry location backing the NTDS\Personal store.


6. Save the changes to the file, and then import it back into the registry:


regedt32 /s SecureLDAP.reg


7. Delete the certificate from the Local Computer Personal store:


certutil -delstore My 9540fd706b336dbd58dfa133f0a7a5e369b83b0a


8. Now all you need to do is force Active Directory to rebind to the certificate. You can do this by:

a. Rebooting the DC.

b. Setting the attribute renewServerCertificate to 1 on the RootDSE of the DC. On core, you can do this with LDIFDE.EXE and an LDIF file.

i. First create the LDIF file (eg, renewCert.ldf):



changetype: modify

add: renewServerCertificate

renewServerCertificate: 1



Be sure to leave a trailing CRLF at the end of the file.

ii. Then use the following command to import the file:


ldifde -f renewCert.ldf -i


After following these steps, you should be able to successfully bind to the DC using the shared alias (I'm assuming that your certificate has a properly configured Subject Alternate Name extension.)”



This worked in our environment.


And a follow-up:

“For removing the old\expired certificates from the NTDS\Personal store, we can simply delete the corresponding registry entry [HKEYLOCALMACHINE\SOFTWARE\Microsoft\Cryptography\Services\NTDS\SystemCertificates\My\Certificates\<thumbprint

of expired cert>]”



chaselton posted this 19 November 2015

Hey Tony,

That is disappointing.  I understand not allowing remote modification of the NTDS certificate store, but leaving out a means to add certificates to the store

locally seems like an oversight to me, unless I’m missing something.


Unfortunately it looks like we’ll be going with the full GUI because of this…something I’d hoped to avoid…



SmitaCarneiro posted this 19 November 2015

Cynthia, According to this link, you cannot do it via Command line tools: But there may be a workaround. In Certificates MMC, if you go to View, Options and select Physical Certificate stores, that will show you where the certificate is stored (registry in this case). Maybe you could script copying the certificate to that location? I’ve never done this, but maybe it’s worth a try? Smita 


chaselton posted this 19 November 2015

Thanks for the suggestion…I’ll keep it in my back pocket just in case.



chaselton posted this 19 November 2015

Wow, thanks!


I’ll test this in our alpha environment.  One question:  does the certificate and private key have to be in the PKCS#12 format?



hcoleman posted this 19 November 2015

I think it only needs to be in PKCS#12 format if you want to use certutil –importfpx (Step 1). If you have other means of getting the certificate and private key into the machine’s personal store, then steps

2 and on will still work.