Enable TLS in Microsoft SQL Server 2022

In a recent post, I described some of the security benefits of using Transport Layer Security (TLS) with Microsoft SQL Server. Configuration changes are required to take full advantage of these capabilities. By default, SQL Server uses an unmanaged, self-signed certificate, which provides little security value. The best practice is to use a certificate issued by the organization’s enterprise PKI. In this guide, I’ll demonstrate how to prepare and deploy a certificate template for SQL server using Active Directory Certificate Services (AD CS), enroll for the certificate, and configure SQL server to use the new certificate for TLS connections.

Note: I have recorded a video demonstration for enabling TLS in Microsoft SQL Server 2022 on my YouTube channel here. Enjoy!

Certificate Requirements

The minimum recommended requirements for a TLS certificate for SQL Server 2022 are:

  • Subject Name = Server’s fully qualified domain name or the alias name of the cluster
  • 2048-bit RSA key with SHA256
  • Server Authentication EKU (1.3.6.1.5.5.7.3.1)

Certificate Template

Administrators must prepare a certificate template in Active Directory (AD) adhering to the requirements listed above. On an issuing certification authority (CA) or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certificate Templates management console (certtmpl.msc) and perform the following steps.

  1. Right-click the default Web Server template and choose Duplicate Template.
  2. Select the Compatibility tab.
    1. In the Compatibility Settings section, select the latest version of Windows Server supported by your issuing CA servers from the Certification Authority drop-down list.
    1. Select Windows 10/Windows Server 2016 from the Certificate recipient drop-down list.
  3. Select the General tab.
    1. Enter a descriptive name in the Template display name field.
    1. Select a validity period of 1 year with a renewal period of 6 weeks.
  4. Select the Cryptography tab.
    1. Select Key Storage Provider from the Provider Category drop-down list.
    1. Select RSA from the Algorithm name drop-down list.
    1. Enter 2048 in the Minimum key size field.
    1. Select SHA256 from the Request hash drop-down list.
  5. Select the Issuance Requirements tab.
    1. Check the box next to CA certificate manager approval.
  6. Select the Subject Name tab.
    1. Select Supply in the request.
  7. Select the Extensions tab.
    1. Select Application Policies.
    1. Ensure that Server Authentication is the only application policy listed.
  8. Select the Security tab.
    1. Click Add.
    1. Grant Read and Enroll permissions to the SQL Server security group or the SQL server’s computer account.
    1. Ensure no other users/groups have enroll permission.

Once complete, publish the certificate template on all issuing CA servers in the organization.

Enroll Certificate

The certificate enrollment process involves several steps.

Request Certificate

To enroll for a new TLS certificate, open the computer certificate management console (certlm.msc) on the SQL server and perform the following steps.

  1. Right-click on the Personal folder and choose All Tasks > Request New Certificate.
  2. Click Next.
  3. Click Next.
  4. Check the box next to the SQL server certificate template.
  5. Click the More information is required to enroll for this certificate. Click here to configure settings link.
  6. Select the Subject tab.
  7. In the Subject Name section, select Common Name from the Type drop-down list.
  8. Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
  9. Click Add.
  10. In the Alternative name section, select DNS from the Type drop-down list.
  11. Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
  12. Click Add.
  13. [OPTIONAL] Enter the SQL server’s single-label hostname in the Value field.

Note: Adding the single-label hostname to the Subject Alternative Name list allows administrators or applications to connect to the SQL server using its short name (NetBIOS name) without resulting in a subject name mismatch error.

  1. Click Add.
  2. Click Ok.
  3. Click Enroll. The status should indicate that enrollment is pending.
  4. Click Finish.

Approve Certificate

Once the certificate request is made, the request must now be approved. On an issuing certification authority (CA), or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certification Authority management console (certsrv.msc) and perform the following steps.

  1. Expand the CA.
  2. Select Pending Requests.
  3. Note the request ID for the pending request. After approval, the request ID will be required later to retrieve the certificate.
  4. Right-click the pending request and choose All Tasks > Issue.

Important Note: I am performing the above tasks in a test lab environment. On a properly configured CA in a production environment, the requestor should not be able to approve their own request. In your environment, you may need to request that a CA administrator review and approve your request.

Install Certificate

Once the certificate has been approved and issued, open an elevated PowerShell or command window on the SQL server and perform the following steps.

  1. Enter certreq.exe -retrieve <request ID>.
  2. Select the CA where the certificate was issued.
  3. Click Ok.
  4. Select a location and enter a name for the file in the File name field.
  5. Click Save.
  6. Enter certreq.exe -accept <path to certificate file>.

Configure Certificate

Once the certificate has been enrolled on the SQL server, expand Personal > Certificates and refresh the view to confirm certificate enrollment. Next, perform the following steps.

  1. Right-click the SQL server certificate and choose All Tasks > Manage Private Keys.
  2. Click Add.
  3. Enter the name of the SQL server domain service account and click Check Names.
  4. If using the default SQL server service account, perform the following steps.
    1. Click on Locations.
      1. Select the local server.
      1. Click Ok.
      1. Enter NT Service\MSSQLSERVER and click Check Names.
  5. Click Ok.
  6. Uncheck Full control. The only permission required is Read.
  7. Click Ok.

SQL Configuration

Next, the new certificate must be assigned to the SQL Server service. Open the SQL Server Configuration Manager (sqlservermanager16.msc) and perform the following steps.

  1. Expand SQL Server Network Configuration.
  2. Right-click Protocols for MSSQLSERVER and choose Properties.
  3. Select the Certificate tab.
    1. Select the new certificate from the Certificate drop-down list.
  4. Select the Flags tab.
    1. Select Yes next to Force Strict Encryption.
  5. Click Ok.

Restart the SQL Server service for the changes to take effect.

Important Note: Selecting Force Strict Encryption will force encryption and certificate validation for all clients connecting to the SQL server. It will override any settings to bypass encryption or certificate checks. Force Strict Encryption may not be compatible with older applications or drivers. Please test thoroughly before enabling this setting.

Video

I’ve published a demonstration video for configuring TLS on Microsoft SQL Server 2022 on YouTube. You can find the video here.

Summary

After completing the configuration steps above, administrators can be assured that all communication between clients and the SQL server is fully protected with TLS using modern cryptography and their enterprise-managed certificate. With TLS enabled for SQL server communication, security is enhanced by encrypting data in transit, ensuring authentication, and protecting sensitive information from interception. In addition, this configuration helps meet compliance requirements.

Additional Information

TLS and Microsoft SQL Server 2022

Always On VPN and SQL Target Principal Name Incorrect

Configure Entra Conditional Access for Always On VPN

Recently, I wrote about Microsoft Always On VPN and Entra Conditional Access and how conditional access improves your organization’s security posture by making policy-based access decisions based on various signals such as user identity, location, device compliance, platform, sign-in risk, and more. In this post, I’ll provide step-by-step instructions for integrating Entra Conditional Access with existing Always On VPN deployments.

Requirements

To use Microsoft Entra Conditional Access with Always On VPN you must have Entra ID P1 at a minimum. To use advanced features such as risk-based policy assessment, you must have Entra ID P2. In addition, all endpoints must be under Intune management; either native Entra ID joined, or hybrid Entra ID joined.

Enable VPN Support

To begin, open the Microsoft Entra admin center (https://entra.microsoft.com/), navigate to Identity > Protection > Conditional Access, and perform the following steps.

  1. Click VPN Connectivity.
  2. Click New certificate.
  3. From the Select duration drop-down list, choose an appropriate certificate validity period.
  4. Click Create.

Once complete, click Download certificate and copy the certificate file to a domain-joined system on-premises.

Publish Certificate

Next, administrators must publish the Entra VPN root certificate in Active Directory to support domain authentication. Open an elevated PowerShell or command window and run the following commands.

certutil.exe -dspublish -f <path to certificate file> RootCA

certutil.exe -dspublish -f <path to certificate file> NtAuthCA

Note: You must be a domain administrator to perform this task.

Conditional Access Policy

Navigate to Identity > Protection > Conditional Access and click Policies, then perform the following steps to create a conditional access policy for VPN access.

  1. Click New Policy.
  2. Enter a descriptive name for the new policy.
  3. Click the link in the Target resources section.
  4. From the Select what this policy applies to drop-down list, select Resources (formerly cloud apps).
  5. In the Include section, choose Select resources.
  6. Click the link in the Select section.
  7. Enter VPN in the search field.
  8. Check the box next to VPN Server.
  9. Click Select.
  10. Click the link in the Grant section.
  11. Select Grant access.
  12. Check the box next to Require device to be marked as compliant.
  13. Click Select.
  14. On the Enable policy slider, select On.
  15. Click Create.

NPS

Changes to Network Policy Server (NPS) policy and configuration are required to support Always On VPN with Entra Conditional Access.

NPS Policy

To update the Always On VPN network policy to support Entra Conditional Access, open the NPS management console (nps.msc), expand Policies, then select Network Policies and perform the following steps.

  1. Right-click on the Always On VPN policy and choose Properties.
  2. Select the Settings tab.
  3. Select Vendor Specific in the RADIUS Attributes section.
  4. Click Add.
  5. Select the Allowed-Certificate-OID attribute.
  6. Click Add.
  7. Click Add.
  8. Enter 1.3.6.1.4.1.311.87 in the Attribute value field.
  9. Click Ok.
  10. Click Ok.
  11. Click Close.
  12. Click Ok.

Important Note: This change will block new Always On VPN user tunnel connections until you update the client configuration. When integrating an existing Always On VPN implementation with Entra Conditional Access, consider creating a new NPS policy and corresponding security group to migrate users to conditional access seamlessly.

NPS Configuration

By default, NPS will perform revocation checks for certificates used for domain authentication. However, Entra Conditional Access uses short-lived certificates (one-hour lifetime) that do not include CRL Distribution Point (CDP) information. Therefore, administrators must change the NPS server configuration to disable revocation checking for certificates lacking this information.

To do this, open the registry editor (regedit.exe) and create a new registry key with the following settings.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13
Name: IgnoreNoRevocationCheck
Type: DWORD
Value: 1

You can also run the following PowerShell command to implement this change.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, the server must be rebooted for the change to take effect.

Client Configuration

After making all required changes to the supporting infrastructure, you must also update the  Always On VPN client configuration to leverage Entra Conditional Access. Changes to client configuration vary depending on the method used to deploy and manage Always On VPN client configuration settings.

Intune

When using Microsoft Intune and the native VPN policy type to deploy and manage Always On VPN client configuration settings, perform the following steps to update the VPN configuration to include Entra Conditional Access support.

  1. Open the Microsoft Intune admin center (https://intune.microsoft.com/) and navigate to Devices > Configuration.
  2. Click on the Always On VPN policy.
  3. Click Edit next to Configuration settings.
  4. Expand the Conditional Access section.
  5. Click Enable next to Conditional access for this VPN connection.
  6. Click Enable next to Single sign-on (SSO) with alternate certificate.
  7. Enter Client Authentication in the Name field.
  8. Enter 1.3.6.1.5.5.7.3.2 in the Object Identifier field.
  9. Enter the organization’s root certification authority (CA) certificate thumbprint in the Issuer hash field.

XML

When using a custom XML configuration file for Always On VPN client configuration settings deployed using Intune or PowerShell, edit the XML file, remove the existing <TLSExtensions></TLSExtensions> section, and replace it with the following.

In addition, add the following code between the <VPNProfile></VPNProfile> tags after <TrustedNetworkDetection>.

Note: You will find a sample XML configuration file you can copy and paste from on GitHub here.

DPC

When using Always On VPN Dynamic Profile Configurator (DPC) for managing Always On VPN client configuration settings, open the DPC group policy and navigate to Computer Configuration > Policies > Administrative Templates > DPC Client > User Tunnel Settings > Advanced and perform the following steps.

  1. Double-click Optional – Device Compliance Settings.
  2. Select Enabled.
  3. Enter 1.3.6.1.5.5.7.3.2 in the Certificate EKU OID field.
  4. Enter the organization’s root certification authority (CA) certificate thumbprint in the Certificate Issuer Hash field.
  5. Click Ok.

Not using DPC? You’re missing out! Learn more about Always On VPN DPC here.

Video

I’ve published a demonstration video for enabling Microsoft Entra ID Conditional Access with Always On VPN on YouTube. You can find the video here.

Summary

Following the guidance in this post to integrate Entra Conditional Access with Always On VPN can significantly improve your organization’s security posture. In the example above, the conditional access policy is a basic one. Yet, it dramatically reduces the attack surface for your remote access infrastructure by ensuring only compliant devices can establish a VPN connection.

Administrators can use advanced conditional access policy settings to strengthen the VPN’s security further by performing additional checks, such as requiring strong, phishing-resistant credentials and requesting multifactor authentication (MFA) for risky sign-ins.

Additional Information

Always On VPN and Entra Conditional Access

Drawback of Multifactor Authentication

Understanding Enterprise Public Key Infrastructure (PKI)

Digital Certificates for Strong Authentication

Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Open Source

Always On VPN Authentication Failure After February 2025 Security Update

Microsoft introduced changes to Windows domain controllers in the February 2025 security update that may result in authentication failures for Always On VPN user tunnel connections. If you suddenly find that all your Always On VPN user tunnel connections fail, additional changes may be required to resolve the issue.

Authentication Failure

Administrators may find that Always On VPN connections fail after applying the February 2025 Microsoft security updates. Specifically, users may receive the following warning message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.”

Error 853

Administrators will also find a corresponding event log entry with event ID 20227 from the RasClient source with the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code returned on failure is 853.”

NPS Events

The event log on the NPS server will also record event ID 6273 from the Microsoft Windows security auditing source with the following error message.

“Network Policy Server denied access to a user.”

The authentication details of the event include Reason Code 16 with the following reason.

“Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.”

DC Events

If the issue is related to changes implemented to domain controllers in the February 2025 security update, administrators will also find a corresponding event log entry on a domain controller with event ID 39 from the Kerberos-Key-Distribution-Center source with the following error message.

“The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping.”

Root Cause

The above conditions indicate that a user attempted to authenticate to the VPN with a certificate that was not strongly mapped. Most likely, the certificate was issued using Microsoft Intune with SCEP or PKCS. This results from changes made to domain controllers in the February 2025 security update that requires certificates used for Active Directory authentication to be strongly mapped. Until now, domain controllers allowed access and only logged an event in the event log when a certificate did not include strong certificate mapping. The February 2025 security update now enforces strong certificate mapping, and authentication requests will fail without it.

Resolution

Administrators must issue new certificates that are strongly mapped to resolve this issue. For certificates issued with PKCS, changes are required on the Intune Certificate Connector server before re-issuing. For certificates issued with SCEP, changes to the device configuration policy are required. See the post Strong Certificate Mapping for Intune PKCS and SCEP Certificates for more details.

Workaround

Re-issuing certificates takes time. To restore connectivity immediately, administrators can implement the following registry settings on all domain controllers to switch back to audit mode and allow authentication without strong certificate mapping.

Key: HKLM:\SYSTEM\CurrentControlSet\Services\Kdc
Name: StrongCertificateBindingEnforcement
Type: DWORD
Value: 1

I recommend deploying this setting via GPO assigned to the Domain Controllers OU. However, you can also implement this change using PowerShell if necessary.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\Kdc’ -Name ‘StrongCertificateBindingEnforcement’ -PropertyType DWORD -Value 1 -Force

Additional Information

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Strong Certificate Mapping Enforcement February 2025

Certificate-Based Authentication Changes and Always On VPN

Intune Strong Certificate Mapping Error

Strong Certificate Mapping Error with PKCS