Or, you could use OpenSSL to convert from whatever format you have into a .pfx file.
From: Coleman, Hunter
Sent: Thursday, November 19, 2015 1:07 PM
To: 'ActiveDir@xxxxxxxxxxxxxxxx' <ActiveDir@xxxxxxxxxxxxxxxx>
Subject: RE: [ActiveDir] Installing AD DS Certificates (in NTDS\Personal) on Server 2012 R2 Core
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.
From:
ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]
On Behalf Of Cynthia Haselton
Sent: Thursday, November 19, 2015 12:43 PM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Installing AD DS Certificates (in NTDS\Personal) on Server 2012 R2 Core
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?
From:
ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]
On Behalf Of Coleman, Hunter
Sent: Thursday, November 19, 2015 1:28 PM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Installing AD DS Certificates (in NTDS\Personal) on Server 2012 R2 Core
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 ldap.Servername.domainname.com
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:
HKLM\SOFTWARE\Microsoft\SystemCertificates\My\Certificates\9540fd706b336dbd58dfa133f0a7a5e369b83b0a
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:
HKEYLOCALMACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates\9540fd706b336dbd58dfa133f0a7a5e369b83b0a
to this:
HKEYLOCALMACHINE\SOFTWARE\Microsoft\Cryptography\Services\NTDS\SystemCertificates\My\Certificates\9540fd706b336dbd58dfa133f0a7a5e369b83b0a
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):
dn:
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>]”
From:
ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]
On Behalf Of Cynthia Haselton
Sent: Thursday, November 19, 2015 8:20 AM
To: 'ActiveDir@xxxxxxxxxxxxxxxx' <ActiveDir@xxxxxxxxxxxxxxxx>
Subject: [ActiveDir] Installing AD DS Certificates (in NTDS\Personal) on Server 2012 R2 Core
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?
