Recover the private key of an SSL PKI certificate.

The SSL certificate is installed but the private key is missing. What are the steps to recover the private key of an SSL certificate in a Microsoft Internet Information Services (IIS) environment?

Cause:

Entrust SSL certificates do not include a private key. The private key resides on the server that generated the Certificate Signing Request (CSR). When installed correctly, the Server Certificate will match up with the private key as displayed below.

    

If the private key is missing, this could mean:

• The certificate is not being installed on the same server that generated the CSR.
• The pending request was deleted from IIS.
• The certificate was installed through the Certificate Import Wizard rather than through IIS.

Solution:
To recover the private key, follow the procedures below.

Part 1 - Snap-In Configuration
Use the following steps to add the Certificates snap-in:

1. Click Start, and then click Run.
   
2. Type in mmc and click OK.
   
3. From the File menu, choose Add/Remove Snap-in.
   
4. In the new window that appears, click Add.
   
5. Select Certificates and then click Add.
   
   

6. Choose the Computer account option and click Next.
   
   

7. Select Local Computer and then click Finish.
   
   

8. Click Close, and then click OK. The snap-in for Certificates (Local Computer) appears in the console.
   
   

Part 2 - Import the Server CertificateUse the following steps to import your Server Certificate into the Personal certificate store. (If the Server Certificate has already been imported into the Personal store, you may skip this step.)

From the MMC console opened in the above steps:

1. Expand the Certificates (Local Computer) tree in the left preview panel.
   
   

2. Right-click Personal and select All Tasks > Import.

 

3. The Certificate Import Wizard appears. Click Next.
   
4. Browse to the location of your Server Certificate file and click Next.
   
   

5. Select Place all certificates in the following store and click Next.
   
   

6. Click Finish to complete the Certificate Import Wizard.
   
   

7. A dialog box appears indicating the import was successful. Click OK.
   
   

Part 3 - Recover the Private Key
Use the following steps to recover your private key using the certutil command.

1. Locate your Server Certificate file (for example, server.cer) and double-click it. The Certificate dialog box appears.
   
   

2. Click the Details tab. Write down the 8-character serial number of the certificate.
   
   

3. Click Start > Run.
   
4. Type cmd and click OK. A Command Prompt window opens.
   
5. Enter the following command at the prompt: 

certutil –repairstore my <serial number>

Where <serial number> is the 8-character serial number obtained in Step 2 (spaces removed).

6.      If Windows is able to recover the private key, you see the following message:

CertUtil:  -repairstore command completed successfully.

7.     If your private key was recovered successfully, your Server Certificate installation is complete. If the private key was not recovered successfully, you will need to generate a new Certificate Signing Request and submit it to Entrust to have your certificate re-issued.

Windows Update error: 0x800b010a Windows Update clients Windows 2008

I couldn't update one of my Windows 2008 R2 servers recently. When I tried I would get the following error code 800B010A or sometimes 0x800B010A; what did it mean?  I couldn't find any good idea's to try whenever I google'd the error code.  So..I figured I would download each patch/fix from Microsoft and manually update the server without trying to use WSUS or the Internet. There were a total of 11 patches/fixes so it wasn't a big deal. After I downloaded, I tried to run the updates manually with the "Run As" option and that didn't work either....WTF!!!

But I did notice that one of the updates actually gave me a good error, not that errors are good, but it lead me in the right direction. The Error was "The certificate chain authority is not valid or missing" Bingo!

Sure enough I ran MMC, Add Snapins, certificates, and checked the Trusted Root Certificate Authority and non of the Microsoft certificates were there?? Sooo...I exported the certs from another Windows 2008 Server and imported the missing certs to my defunct server and WALA!!! back in business, my server can now update via WSUS and the internet.

Missing Certs " Microsoft Root Authority - expiration 12/31/2020"
                      " Microsoft Root Certificate Authority - expiration 5/9/2021"


This may not be the case with your issue, but it helped resolve mine!

Ciphers TLS SSL Encryption Methods and FIPS 140-1 cipher suites in XP,W2K3,W2K8

Schannel Specific Registry Keys

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

SCHANNEL Key

Start Registry Editor (Regedt32.exe), and locate the following key in the registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

SCHANNEL\Protocols SubKey

To enable the use of the protocols that will not be negotiated by default (such as TLS 1.1 or TLS 1.2), change the DWORD value data of the DisabledByDefault value to 0x0 in each of the following registry keys under the Protocols key:

• SCHANNEL\Protocols\TLS 1.1\Client
• SCHANNEL\Protocols\TLS 1.1\Server
• SCHANNEL\Protocols\TLS 1.2\Client
• SCHANNEL\Protocols\TLS 1.2\Server

WARNING: The DisabledByDefault value in the registry keys under the Protocols key does not take precedence over the grbitEnabledProtocols value that is defined in the SCHANNEL_CRED structure that contains the data for an Schannel credential.

SCHANNEL\Ciphers Subkey

The Ciphers registry key under the SCHANNEL key is used to control the use of symmetric algorithms such as DES or RC4. The following are valid registry keys under the Ciphers key.

SCHANNEL\Ciphers\RC4 128/128 Subkey:

RC4 128/128

This subkey refers to 128-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled. This registry key does not apply to an exportable server that does not possess an SGC certificate.

Disabling this algorithm effectively disallows:

• SSL_RSA_WITH_RC4_128_MD5
• SSL_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA

SCHANNEL\Ciphers\Triple DES 168/168 Subkey:

Triple DES 168

This registry key refers to 168-bit Triple DES as specified in ANSI X9.52 and Draft FIPS 46-3. This registry key does not apply to the export version.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD data to 0x0. If you do not configure the Enabled value, the default is enabled.

Disabling this algorithm effectively disallows:

• SSL_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

SCHANNEL\Ciphers\RC2 128/128 Subkey:

RC2 128/128

This registry key refers to 128-bit RC2. It does not apply to the export version.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

SCHANNEL\Ciphers\RC4 64/128 Subkey:

RC4 64/128

This registry key refers to 64-bit RC4. It does not apply to the export version (but is used in Microsoft Money).

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

SCHANNEL\Ciphers\RC4 56/128 Subkey:

RC4 56/128

This registry key refers to 56-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

Disabling this algorithm effectively disallows:

• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

SCHANNEL\Ciphers\RC2 56/128 Subkey:

RC2 56/128

This registry key refers to 56-bit RC2.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

SCHANNEL\Ciphers\RC2 56/56 Subkey:

DES 56

This registry key refers to 56-bit DES as specified in FIPS 46-2. Its implementation in the Rsabase.dll and Rsaenh.dll files has been validated under the FIPS 140-1 Cryptographic Module Validation Program.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

Disabling this algorithm effectively disallows:

• SSL_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA

SCHANNEL\Ciphers\RC4 40/128 Subkey:

RC4 40/128

This refers to 40-bit RC4.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

Disabling this algorithm effectively disallows:

• SSL_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC4_40_MD5

SCHANNEL\Ciphers\RC2 40/128 Subkey:

RC2 40/128

This registry key refers to 40-bit RC2.

To allow this cipher algorithm, change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0. If you do not configure the Enabled value, the default is enabled.

Disabling this algorithm effectively disallows:

• SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

SCHANNEL\Ciphers\NULL Subkey:

NULL

This registry key means no encryption. It is turned off by default.

To turn off encryption (disallow all cipher algorithms), change the DWORD value data of the Enabled value to 0xffffffff, otherwise change the DWORD value data to 0x0.

SCHANNEL/Hashes Subkey

The Hashes registry key under the SCHANNEL key is used to control the use of hashing algorithms such as SHA-1 or MD5. The following are valid registry keys under the Hashes key.

SCHANNEL\Hashes\MD5 Subkey:

MD5

To allow this hashing algorithm, change the DWORD value data of the Enabled value to the default value 0xffffffff, otherwise change the DWORD value data to 0x0.

Disabling this algorithm effectively disallows:

• SSL_RSA_EXPORT_WITH_RC4_40_MD5
• SSL_RSA_WITH_RC4_128_MD5
• SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

SCHANNEL\Hashes\SHA Subkey:

SHA

This registry key refers to Secure Hash Algorithm (SHA-1), as specified in FIPS 180-1. Its implementation in the Rsabase.dll and Rsaenh.dll files has been validated under the FIPS 140-1 Cryptographic Module Validation Program.

To allow this hashing algorithm, change the DWORD value data of the Enabled value to the default value 0xffffffff, otherwise change the DWORD value data to 0x0.

Disabling this algorithm effectively disallows:

• SSL_RSA_WITH_RC4_128_SHA
• SSL_RSA_WITH_DES_CBC_SHA
• SSL_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
• SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

SCHANNEL/KeyExchangeAlgorithms Subkey

The KeyExchangeAlgorithms registry key under the SCHANNEL key is used to control the use of key exchange algorithms such as RSA. The following are valid registry keys under the KeyExchangeAlgorithms key.

SCHANNEL\KeyExchangeAlgorithms\PKCS Subkey:

PKCS

This registry key refers to the RSA as the key exchange and authentication algorithms.

To allow RSA, change the DWORD value data of the Enabled value to the default value 0xffffffff, otherwise change the DWORD data to 0x0.

Disabling RSA effectively disallows all RSA-based SSL and TLS cipher suites supported by the Windows NT4 SP6 Microsoft TLS/SSL Security Provider.

FIPS 140-1 Cipher Suites

You may want to use only those SSL 3.0 or TLS 1.0 cipher suites that correspond to FIPS 46-3 or FIPS 46-2 and FIPS 180-1 algorithms provided by the Microsoft Base or Enhanced Cryptographic Provider.

In this article, we refer to them as FIPS 140-1 cipher suites. Specifically, they are:

• SSL_RSA_WITH_DES_CBC_SHA
• SSL_RSA_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

To use only FIPS 140-1 cipher suites as defined above, supported by Windows NT 4.0 Service Pack 6 Microsoft TLS/SSL Security Provider with Microsoft Base or Enhanced Cryptographic Provider, configure the DWORD value data of the Enabled value in the following registry keys to 0x0:

• SCHANNEL\Ciphers\RC4 128/128
• SCHANNEL\Ciphers\RC2 128/128
• SCHANNEL\Ciphers\RC4 64/128
• SCHANNEL\Ciphers\RC4 56/128
• SCHANNEL\Ciphers\RC2 56/128
• SCHANNEL\Ciphers\RC4 40/128
• SCHANNEL\Ciphers\RC2 40/128
• SCHANNEL\Ciphers\NULL
• SCHANNEL\Hashes\MD5

and configure the DWORD value data of the Enabled value in the following registry keys to 0xffffffff:

• SCHANNEL\Ciphers\DES 56/56
• SCHANNEL\Ciphers\Triple DES 168/168" [not applicable in export version]
• SCHANNEL\Hashes\SHA
• SCHANNEL\KeyExchangeAlgorithms\PKCS

Master Secret Computation Using FIPS 140-1 Cipher Suites

The procedures for using the above FIPS 140-1 cipher suites in SSL 3.0 are different from those for using (the above) FIPS 140-1 cipher suites in TLS 1.0.

In SSL 3.0, the following is the definition master_secret computation:

In TLS 1.0, the following is the definition master_secret computation:

where:

Selecting the Option to Use Only FIPS 140-1 Cipher Suites in TLS 1.0:

Because of the above difference, customers may want to prohibit the use of SSL 3.0, even though the allowable set of cipher suites has been limited to only the subset of FIPS 140-1 cipher suites. In that case, change the DWORD value data of the Enabled value to 0x0 in each of the following registry keys under the Protocols key:

• SCHANNEL\Protocols\SSL 3.0\Client
• SCHANNEL\Protocols\SSL 3.0\Server

WARNING: The Enabled value data in these registry keys under the Protocols key take precedence over the grbitEnabledProtocols value defined in the SCHANNEL_CRED structure containing the data for an Schannel credential. The default Enabled value data is 0xffffffff.

Example Registry Files

Two examples of registry file content for purposes of configuration, Export.reg and Non-export.reg, are provided in this section of the article.

In a computer running Windows NT 4.0 Service Pack 6 with the exportable Rasbase.dll and Schannel.dll files, run Export.reg to ensure that only TLS 1.0 FIPS cipher suites are used by the computer.

In a computer running Windows NT 4.0 Service Pack 6 that includes the non-exportable Rasenh.dll and Schannel.dll files, run Non-export.reg to ensure that only TLS 1.0 FIPS cipher suites are used by the computer.

For the Schannel.dll file to recognize any changes under the SCHANNEL registry key, you must restart the computer.

To return the registry settings to default, delete the SCHANNEL registry key and everything under it. If these registry keys are not present, the Schannel.dll rebuilds the keys when you restart the computer.

Nessus Vulnerability: SSL Weak Cipher supported (3071/tcp)

Vulnerability : SSL Medium Strength Cipher Suites Supported -Medium [Nessus] [csd-mgmt-port (3071/tcp)]
 
Description :
The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits.
 
Fix :
Reconfigure the affected application if possible to avoid use of medium strength ciphers.


The output of the Nessus report will show what ports have been detected to have vulnerabilities. In my case the findings were located on "3071/tcp" with 8 plugins/ID's on this same port. The problem with the report is that it doesn't show you how to fix or resolve the problem other than "Reconfigure the affected application", OK!, Which application has the known vulnerability?. Just by looking at the details of the report I really couldn't figure out which one was causing the findings.

After a few google attempts and registry hacks I wasn't making any progress. Then I remembered from my Cisco/Networking years, some things you just never forget...slow to recall at times but still there, that each OS tracks applications that are running that require network connectivity or not. Sooo...I know the port I'm looking for 3071, then I jumped onto a XP box, This also applies to Windows 2008/W7, go to the command line and run "NETSTAT -ano" and a list of all the applications is shown.

• Go to the command prompt (Start>Run>cmd)
• Enter netstat -ano
• You will get a report of Active Connections
• Report includes: Protocol, Local Address, Foreign Address, State, PID
• e.g.
  • Proto Local Address Foreign Address State PID
  • UDP 127.0.0.1:3071 *:* 3071
• Scroll down through the list until you find x.x.x.x:3071 in the LISTENING state.
• Write down the PID (process identifier) associated with port 3071 (Also note the Local Address, Foreign Address, Protocol and State.)

 

• Next, start the Windows Task Manager, Select the Processes tab in Task Manager and search for the PID you wrote down previously and Whala! that's your application that's causing the vulnerability to be flagged!
• In my case it was JAVAW.EXE, Dell had loaded a RAID software management program that started javaw.exe each time the workstation was started. I simply followed the path to the file and renamed the one particular file to "JAVAW.OLD". restarted the workstation, reran the Nessus scan and the Vulnerability was gone and the program continued to function without a problem!
  
  HOPE THIS HELPS!
  
  NOTE: Same thing happened on one of my Windows2008 R2 Servers running CA ArcServe. I followed the same steps and AGAIN! Java.exe was the culprit. renamed "Java.exe" to "Java.old" and CA ArcServe continued to run without a problem. 
  
• netstat parameter -s displays per-protocol statistics. By default, statistics are shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6

Identifying a Domain Controller GUID on Windows 2003

Applies To: Windows Server 2003 with SP1 or SP2


Note: Tried this recently on Windows 2008 R2 and it worked as well.

Identifying the correct domain controller GUID for an SMTP replication certificate may pose a challenge for some administrators who are unfamiliar with the nuances of Active Directory and domain controller objects in the directory. To determine a specific domain controller GUID from a Windows XP or Windows Server 2003 computer joined to the Active Directory forest, perform the following steps.

Note
The dsquery utility is part of the Windows Server 2003 Administration Tools Pack and is not available on Windows 2000 computers.

1. Log on to the computer with a domain account.
2. From a command-line prompt, run the following command.
   dsquery * “CN=<hostname>,OU=Domain Controllers,DC=<yourdomain>,

   DC=<yourdomain>” –scope base –attr objectguid

   You must replace the <hostname> variable with the name of the specific domain controller you want and the <yourdomain> variable with the domain name of your specific domain.
   
   For example:

   dsquery * “CN=DC01,OU=Domain Controllers,DC=contoso,DC=com” –scope base –attr objectguid
   

   The command will result in output similar to the following:
   Objectguid 
   {57A8AAF4-686E-4128-8712-B6CA89FBF5BC}

3. Log off the computer.

Creating WIndows 2008 Self-Signed Certificates

Creating a Self-Signed Certificate on Windows Server 2008/2008 R2 without IIS

Warning: Enterprise Root CA services need to be designed and implemented properly rather than simply installed on a whim to generate a certificate!

Problem

It's not possible to generate a self-signed certificate on Windows Server 2008/2008 R2 without having to install IIS.

Option #1

Back in Windows 2003 with IIS6 there was a tool called SelfSSL to generate and assign self-signed certificates. SelfSSL is bunded with Microsoft’s IIS 6.0 Resource Kit Tools
SelfSSL is technically not compatible with IIS 7.0 however we found out that we can still use it to generate a self-signed certificate on newer servers!
Download and install SelfSSL only, no additional tools are needed from the kit

Launch SelfSSL by going to Start >Programs > IIS Resources > SelfSSL > SelfSSL
(Note: You must run SelfSSL elevated as an Administrator)

selfssl.exe /N:CN=fqdn.domain.server /K:2048 /V:365

The above command will generate a new certificate with a key length of 2048 and a validity period of 1 year (365 days).

When prompted to overwrite the settings for site 1, answer with yes.
* An error opening the metabase will appear but can be ignored due to IIS not being installed on the server.
You will now be able to find the certificate in the local computer certificate store ready for use.

Option#2

Use OpenSSL to generate certificate for SSL connections.

 Preparation:
1. Download OpenSSL installer from the following link: http://slproweb.com/download
If you have problem on running OpenSSL, you may also need to download and install the Visual C++ 2008 installer.

2. Open the command prompt (Run As Administrator) and open the bin folder of the installation path. In this instance the default is: "C:\OpenSSL-Win32\bin"



Procedure:
1. command syntax: openssl genrsa -out priv.key 2048 
Note: You might get a warning message: “can’t open config file: /usr/local/openssl.cnf”. In this instance you need to set the path to the .cfg file supplied with installation. Set the path with the following command: Set OPENSSL_CONF=C:\OpenSSL-Win32\bin\openssl.cfg. If you get no messages then command succeeded.
3. Input the following command: openssl req -new -key priv.key -out server.crt -x509 -days 365. This generates a public key(cert) according to the private key generated above with expiration date 365 days, in X509 format.
You will be asked to enter the following information:

1. Country Name (2 letter code) [AU]:
2. State or Province Name (full name) [Some-State]:
3. Locality Name (eg, city) []:
4. Organization Name (eg, company) [Internet Widgits Pty Ltd]:
5. Organizational Unit Name (eg, section) []:
6. Common Name (e.g. server FQDN or YOUR name) []:xyz.MyCloudNas.com
7. Email Address []:

Enabling Smart Card Login for Windows 2008

Domain Controller Certificate Installation

PKI-issued domain controller (DC) certificates must be installed on all DCs in the enterprise.

Action for Windows Server 2008 R2 users: The Force strong key protection for user keys stored on the computer setting will need to be temporarily relaxed via Group Policy while the certificate request is generated. When this setting is set to User must enter a password each time they use a key, a Key Protection password is required for use of the Domain Controller’s private key. This will cause silent operations such as Smart Card Logon/Mutual Authentication to fail. Perform these steps before requesting the Domain Controller certificate.

1) Open the Group Policy Management console. Select Start > Administrative Tools > Group Policy Management.
2) Expand Forest > Domains > your domain.
3) Expand Domain Controllers. Right-click Default Domain Controllers Policy and select Edit.
4) Expand Computer Configuration/Policies/ Windows Settings/Security Settings/Local Policies. Select Security Options.
5) Double-click System Cryptography: Force strong key protection for user keys stored on the computer.
6) Set this setting to User input is not required when new keys are stored and used.
7) Restart the system.

Generate the Certificate Request on the Domain Controller
1) Open the Certificates snap-in in MMC. Navigate to Start >Run and enter MMC. Click OK.
2) Navigate to File > Add/Remove Snap-in.
3) At the Add/Remove Snap-in screen select Add.
4) Select the Certificates snap-in and click Add.
5) Select Computer Account for the type of certificates to manage. Click Next.
6) Select Local Computer as the computer to manage. Click Finish.
7) When returned to the Add/Remove Snap-in screen click Ok.
8) At the main MMC window, the Certificates (Local Computer) snap-in should appear. Expand Certificates (Local Computer), Personal. Right-click on Certificates and select All Tasks, Advanced Operations Create custom request.
9) Click Next.

Note: For Windows Server 2008 R2, select the Custom Request Proceed without Enrollment Policy on the next screen.

10) Select the template (No template) Legacy key. Check the Suppress default extensions box. Ensure PKCS #10 is selected. Click Next.
Note: For Windows Server 2008 R2, select the (No Template) CNG Key.

11) Click the drop down arrow next to Details and click the Properties button.
12) On the Subject tab under Subject name, select the drop-down type Common name. Enter the domain controller’s Fully Qualified Domain Name (FQDN), e.g. dc1.contoso.com
13) Click the Add button and the subject will appear on the right side in the form CN=<FQDN> (e.g., CN=dc1.contoso.com).
14) On the Private Key tab, expand Key options. Select the Key size 2048 and check only the box Make private key exportable. Click OK.
15) At the Certificate Information screen, verify the details and click Next.
16) Enter the file name to save the certificate request or click the Browse button to select a file path. Name the request with a .txt extension. Ensure the Base 64 radio button is selected. Click Finish to save the request and exit the certificate request wizard.

Note: If you are running Windows Server 2008 R2 and relaxed the Force strong key protection for user keys stored on the computer setting, you can reset it back to its original value now by following the same steps used at the beginning of this section to relax it, but setting the value to User must enter a password each time they use a key in step 7.

Submit the DC Certificate Request to your CA (Server)
1) Open a web browser and navigate to the CA URL:

https://caserver.domain.com/

2) Scroll down the list and select the profile for Manual PKCS10 Domain Controller 2048-bit Certificate Enrollment.
3) In Notepad, open the certificate .txt request file generated in the previous section. Copy the encoded certificate request from the text file and paste it into the Certificate Request field on the web site.
4) Click Submit.
5) Once the cert has approved and issued the certificate will be available for download.
Navigate to the URL with a web browser.

https://caserver.domain.com/

6) Click the Retrieval Tab, enter your request number and hit Submit.
7) Click on the Issued certificate (serial number) link.
8) Verify that the certificate and form contents are correct. Scroll down to the base 64-encoded certificate, highlight and copy the certificate to the clipboard, including the ----- BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags.
9) Open Notepad and paste the certificate into a text file. Save the file to an easily accessible location; use All Files as the Save As Type, and save with a .cer extension. If the system from which the certificate is retrieved is different from the domain controller from which the request was generated, the retrieved certificate must be transported to the requesting domain controller via removable media or copied via the network.

Install the DC Certificate
1) Open a command prompt by clicking Start Run and typing cmd.
2) Within the command prompt, navigate to the location where the certificate file is located using the cd command. Install the certificate by typing the following command:
certreq –accept <file>.cer

Verify the DC Certificate
Open the certificate in MMC.
1) Navigate to Start  Run and enter mmc. Click OK.
2) Select File Add/Remove Snap-in.
3) At the Add/Remove Snap-in screen, select Add.
4) Select the Certificates snap-in and click Add.
5) Select Computer Account for the type of certificates to manage. Click Next.
6) Select Local Computer as the computer to manage. Click Finish.
7) When returned to the Add/Remove Snap-in screen click OK.
8) At the main MMC window, the Certificates (Local Computer) snap-in should appear. Expand Certificates (Local Computer) Personal Certificates.
9) Observe the certificate for this domain controller is in the local computer’s personal certificate store. Ensure the certificate is verified and has a valid private key.
10) Close all windows from this section.