Secure Your Windows Server 2012 Intranet: Installing a Self-Signed Certificate with SHA256

In today’s security landscape, ensuring the confidentiality and integrity of your intranet websites is paramount. For many organizations utilizing Windows Server 2012, self-signed certificates offer a practical solution for securing internal web traffic. However, the default method for generating these certificates in Windows Server 2012 R2 (IIS 8.5) utilizes the SHA1 signature hash algorithm, which is now considered outdated and insecure. The industry is actively moving away from SHA-1 due to its known vulnerabilities.

This comprehensive guide will walk you through the process of creating and installing a self-signed certificate on Windows Server 2012 that leverages the more robust SHA256 signature hash algorithm. By following these steps, you can enhance the security of your intranet environment and align with modern security best practices.

Why Choose SHA256 for Self-Signed Certificates?

The SHA-1 hashing algorithm has been deprecated by Microsoft and the wider security community due to potential collision vulnerabilities. This means that it is theoretically possible for attackers to create different pieces of data that produce the same SHA-1 hash, undermining the security guarantees of certificates signed with this algorithm. In contrast, SHA256 is a stronger and more secure hashing algorithm that is resistant to known attacks and is the recommended standard for digital signatures.

By using SHA256 for your self-signed certificates, you are proactively mitigating risks associated with SHA-1 and ensuring a higher level of security for your internal web applications. This is especially crucial as browsers and operating systems increasingly warn users about or outright block connections secured by SHA-1 certificates.

Prerequisites

Before you begin, ensure you have the following:

• Windows Server 2012 R2: This guide is specifically tailored for Windows Server 2012 R2.
• Administrator Privileges: You need administrator access to the Windows Server to perform certificate management tasks.

Step-by-Step Guide: Generating a SHA256 Self-Signed Certificate Using MMC

To create a self-signed certificate with the SHA256 algorithm, we will utilize the Microsoft Management Console (MMC). This method provides greater control over the certificate generation process compared to the default IIS Manager method.

Step 1: Open MMC Console

1. Open the Run dialog: Press Win + R keys simultaneously.
2. Type mmc: In the Run dialog box, type mmc and click OK. This will open the MMC console.

This image illustrates the first step of opening the MMC console by typing ‘mmc’ in the Run dialog, a crucial starting point for managing certificates.

Step 2: Add Certificates Snap-in

1. Click on “File” in the MMC console menu.
2. Select “Add/Remove Snap-in…” from the dropdown menu.

This screenshot shows the “Add/Remove Snap-in” option under the File menu in the MMC console, essential for accessing certificate management features.

3. In the “Add or Remove Snap-ins” window, select “Certificates” from the “Available snap-ins” list and click “Add >”.

Here, the “Certificates” snap-in is selected from the list of available snap-ins, preparing to add it to the MMC console for certificate management.

4. In the “Certificates snap-in” dialog, choose “Computer account” and click “Next”. This ensures the certificate is managed for the entire computer.

This image highlights the selection of “Computer account” for the Certificates snap-in, indicating that the certificate operations will affect the entire machine.

5. Ensure “Local computer” is selected and click “Finish”.

This step confirms that the certificate management will be performed on the “Local computer,” which is the Windows Server 2012 R2 machine itself.

6. Click “OK” in the “Add or Remove Snap-ins” window. The “Certificates (Local Computer)” snap-in is now added to your MMC console.

This final screenshot of this step confirms the successful addition of the “Certificates (Local Computer)” snap-in to the MMC console, ready for certificate operations.

Step 3: Create Custom Certificate Request

1. Expand “Certificates (Local Computer)” in the left pane of the MMC console.
2. Navigate to “Personal” > “Certificates”.
3. Right-click on “Certificates”, go to “All Tasks”, then “Advanced Operations”, and finally select “Create Custom Request…”.

This image shows the navigation through the MMC console to initiate a “Custom Certificate Request,” a crucial step in generating a certificate with specific configurations.

4. In the “Certificate Enrollment” wizard, click “Next”.

The first screen of the Certificate Enrollment wizard is displayed, prompting the user to proceed with the certificate request process.

5. Select “Proceed without enrollment policy” and click “Next”. We are creating a self-signed certificate, so no enrollment policy is needed.

This step highlights the selection of “Proceed without enrollment policy,” appropriate for generating a self-signed certificate that doesn’t require an external certificate authority.

6. Choose “(No Template) CNG key” under “Template” and “PKCS #10” under “Request format”. Click “Next”.

This image focuses on choosing “(No Template) CNG key” and “PKCS #10” as the template and request format, respectively, for a custom certificate request.

Step 4: Configure Certificate Properties

1. Click on the “Details” dropdown arrow and then click the “Properties” button.

This screenshot shows how to access the “Properties” dialog within the Certificate Enrollment wizard to configure detailed settings for the certificate.

2. In the “Certificate Properties” window, go to the “General” tab. Enter a “Friendly name” for your certificate. This name is for your identification within the certificate store and does not affect the certificate’s functionality.

3. Navigate to the “Subject” tab. Under “Subject name”, select “Common name” from the “Type” dropdown. In the “Value” field, enter the hostname or fully qualified domain name (FQDN) of your Windows Server 2012. Click “Add”. This common name should match the address users will use to access your website.

4. Still in the “Subject” tab, under “Alternative name”, select “DNS” from the “Type” dropdown. In the “Value” field, enter your domain name or any other DNS entries that should be associated with this certificate. Click “Add”. You can add multiple DNS entries if needed.

This image illustrates the configuration of “Subject” and “Alternative Names” in the certificate properties, where the Common Name (hostname) and DNS entries are added.

5. Go to the “Extensions” tab. Select “Extended Key Usage”. Click “Add…”. In the “Add Extended Key Usage” dialog, select “Server Authentication” and click “OK”. This specifies that the certificate is intended for server authentication, which is essential for HTTPS websites.

Here, “Extended Key Usage” is being configured to include “Server Authentication,” specifying that the certificate is intended for securing server communications like HTTPS.

6. Select “Basic Constraints” in the “Extensions” tab. Check the box “Enable this extension”. Ensure “Make this certificate authority” is not checked, as this is a self-signed certificate and not intended to be a certificate authority.

This step shows the configuration of “Basic Constraints,” specifically enabling the extension without making the certificate a Certificate Authority, which is typical for self-signed certificates.

7. Navigate to the “Private Key” tab, and then expand “Key options”. Check the box “Make private key exportable”. This will allow you to export the certificate along with its private key later, which is necessary for importing it into IIS and other systems.

This image emphasizes the important step of making the private key exportable, which is necessary for deploying the certificate to web servers and other systems.

8. Still in the “Private Key” tab, expand “Key Options” and then expand “Hash Algorithm”. From the “Hash algorithm” dropdown, select “sha256”. This is the crucial step to ensure your self-signed certificate uses the SHA256 algorithm.

This critical step highlights the selection of “sha256” as the Hash algorithm, ensuring that the generated self-signed certificate utilizes the stronger SHA256 encryption.

9. Click “Apply” and then “OK” to close the “Certificate Properties” window.

Step 5: Generate and Save the Certificate Request

1. Click “Next” in the “Certificate Enrollment” wizard.

This step shows the continuation of the Certificate Enrollment wizard, moving towards generating the certificate request file.

2. Select “Base64 encoded” as the request format.
3. Click “Browse…” to choose a location to save the certificate request file. Name the file with a .req extension (e.g., CertName.req). Click “Finish”. This will save the certificate request to the specified location.

Here, the user is prompted to save the certificate request file, typically with a ‘.req’ extension and Base64 encoding, preparing for the next stage of certificate creation.

Step 6: Import the Certificate

While we created a certificate request, MMC in this context also generates and installs the self-signed certificate directly into the certificate store. We now need to import it to ensure it’s correctly placed.

1. In the MMC console, navigate back to “Certificates (Local Computer)” > “Personal” > “Certificates”.
2. Right-click on “Certificates”, go to “All Tasks”, and select “Import…”.

This image shows the initiation of the certificate import process from the MMC console, allowing the user to bring the newly created certificate into the certificate store.

3. In the “Certificate Import Wizard”, click “Next”.

The first screen of the Certificate Import Wizard is displayed, guiding the user through the steps to import a certificate into the system.

4. Click “Browse…” and locate the certificate file you just created (the .cer file – you might need to change the file type filter to “All Files” to see it, or select “Certificate Enrollment Requests” in the left pane and find the generated certificate there, then export it to a .cer file as described in the original article steps 28-29 if you cannot locate the .cer file directly). Select the certificate file and click “Open”.

This step involves browsing and selecting the certificate file (typically with a ‘.cer’ extension) that will be imported into the Windows Certificate Store.

5. Ensure “Place all certificates in the following store” is selected, and the store is set to “Personal”. Click “Next”.

This image confirms that the imported certificate will be placed in the “Personal” certificate store on the local computer, a standard location for user-specific certificates.

6. Click “Finish” to complete the import process.

The final step of the Certificate Import Wizard, prompting the user to click “Finish” to complete the import operation and add the certificate to the store.

7. Click “OK” on the “The import was successful” message box.

Step 7: Export and Verify the Certificate (Optional but Recommended)

1. To verify the SHA256 algorithm, double-click the imported certificate in the “Certificates (Local Computer)” > “Personal” > “Certificates” list.

2. Go to the “Details” tab. Scroll down and find the “Signature hash algorithm” field. It should display “sha256”.

3. (Optional) To export the certificate for use on client machines, go to the “Details” tab, click “Copy to File…”, and follow the Certificate Export Wizard to export it as a .cer file (without the private key, which should remain secure on the server).

Step 8: Import Certificate to IIS and Client Machines

1. Import to IIS: To use this certificate with your website in IIS, open IIS Manager, navigate to your website bindings, add or edit an HTTPS binding, and select your newly created certificate from the “SSL certificate” dropdown.

2. Import to Client Machines: For client machines to trust this self-signed certificate without browser warnings, you need to import the exported certificate (from step 7, if you chose to export) into the “Trusted Root Certification Authorities” store on each client machine. Follow similar steps as in Step 2 & 6 above on the client machine’s MMC, but import into the “Trusted Root Certification Authorities” store instead of “Personal”.

   • On Client Machines:
     • Run mmc.
     • Add the “Certificates” snap-in, selecting “Computer account”.
     • Import the certificate into “Trusted Root Certification Authorities” > “Certificates”.

Conclusion

By following these detailed steps, you have successfully created and installed a self-signed certificate with the SHA256 signature hash algorithm on your Windows Server 2012 R2. This significantly enhances the security of your intranet websites by moving away from the deprecated SHA-1 algorithm. Remember to import the certificate into the Trusted Root Certification Authorities on client machines to avoid browser warnings. Securing your internal web applications with robust certificates is a crucial step in maintaining a secure and trustworthy IT environment.