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

TLS and Microsoft SQL Server 2022

Transport Layer Security (TLS) for SQL Server 2022 has numerous benefits. TLS enhances SQL Server security by providing authentication, encrypting data in transit, ensuring regulatory compliance, and following security best practices. It helps prevent unauthorized access, protects sensitive information, and mitigates interception attacks, making it a critical component of a secure database environment.

Self-Signed Certificates

When installing Microsoft SQL Server 2022 on-premises, a self-signed certificate is automatically created to support Transport Layer Security (TLS) connections to the database. From a security perspective, using unmanaged, self-signed certificates is never a good idea.

Risk

Self-signed certificates are insecure because they are not issued by a trusted Certification Authority (CA), making it impossible to verify the legitimacy of the server. This lack of trust enables attackers to intercept and manipulate data through interception attacks. Additionally, since operating systems do not automatically trust self-signed certificates, users may ignore security warnings, increasing the risk of connecting to malicious or compromised servers.

Enterprise PKI Certificates

For production workloads, security best practices dictate using enterprise PKI-issued and managed certificates, which provide many security benefits.

Authentication

TLS with managed certificates provides a mechanism for server authentication, ensuring that clients connect to a legitimate server and not an impostor. TLS authentication helps mitigate interception attacks where an attacker could potentially impersonate the server. Managed TLS certificates can also be revoked in the event of key compromise.

Data Encryption

Microsoft SQL Server 2022 database servers often store sensitive data, including personal details, financial records, and other confidential business information. TLS ensures that data in transit between the client and the server is encrypted using modern cryptography, which enhances privacy and confidentiality while preventing unauthorized interception and eavesdropping.

Compliance Requirements

Many regulatory frameworks and compliance standards, such as GDPR, HIPAA, or PCI-DSS, require or strongly recommend encrypting data in transit. Enabling TLS on SQL Server helps meet these compliance standards, strengthens internal security protections, and avoids potential penalties.

Security Best Practice

Implementing TLS is considered a fundamental security best practice in network and data communication. It reduces the risk of data breaches and enhances the overall network security posture in the enterprise.

TLS and SQL Server 2022

Microsoft SQL Server 2022 includes critical new options for administrators. The “Force Encryption” and “Force Strict Encryption” flags control how encryption is enforced for client connections, but their behavior and compatibility requirements differ.

Force Encryption

When this setting is enabled, the SQL server will encrypt communication between the client and server using TLS. However, contrary to what the name of the setting implies, it is possible for the server to accept unencrypted connections in some cases. If the client does not support encryption, the connection may still succeed without encryption. Enabling Force Encryption prioritizes encryption but does not strictly enforce it, meaning older clients that do not support encryption can still connect. Administrators can use this setting to ensure backward compatibility for applications that may not support strict encryption policies. However, upgrading applications to support encryption is strongly advised.

Force Strict Encryption

This setting is subtly different than the previous setting. It also ensures that all communication between the client and the server is encrypted without exception. If a client does not support encryption, the connection will be rejected. In addition, this setting enforces enhanced security parameters for the connection, such as certificate validation, more secure TLS cipher suites, and the use of TLS 1.3* when available. Force Strict Encryption is designed for modern security compliance. It is the preferred setting and should be used when all clients are known to support encryption.

* Note: TLS 1.3 is supported with SQL Server 2022 cumulative update 1 or later installed.

Key Differences

The following table summarizes the key differences between Force Encryption and Force Strict Encryption.

Force EncryptionEncourages but does not require encryption. Unencrypted connections may still be allowed.
Force Strict EncryptionRequires encryption for all connections. Clients that do not support encryption will be rejected.

Summary

By securing your Microsoft SQL Server with TLS, you significantly enhance the security, reliability, and trustworthiness of your data management systems. In the next post, I’ll provide detailed step-by-step guidance for enabling and configuring TLS on Microsoft SQL Server 2022 using best security practices.

Additional Information

Step-by-Step Guide: Enable TLS in Microsoft SQL Server 2022

VIDEO: Enable TLS in Microsoft SQL Server 2022

Microsoft SQL Server 2022

Microsoft Intune Cloud PKI and Certificate Templates

Microsoft recently announced the general availability of its new PKI-as-a-Service platform called Microsoft Intune Cloud PKI. With Intune Cloud PKI, administrators create certification authorities (CAs) to issue and manage user and device authentication certificates for Intune-managed endpoints. Cloud PKI also provides hosted Authority Information Access (AIA) and Certificate Revocation List (CRL) Distribution Point (CDP) services, in addition to Simple Certificate Enrollment Protocol (SCEP) service, so administrators do not have to deploy on-premises infrastructure to take advantage of certificate-based authentication.

Certificate Templates

After deploying your Intune Cloud PKI root and issuing CAs, you may wonder where to find the associated certificate templates. If you are familiar with traditional on-premises Active Directory Certificate Services (AD CS) implementations, this is how you define the purpose, key policy, security parameters, and lifetime of the certificate issued using that template. However, Intune Cloud PKI does not use certificate templates in the traditional way many administrators are familiar with.

Note: Microsoft may introduce support for certificate templates for Intune Cloud PKI in the future. However, it is not supported at the time of this writing.

SCEP Profile

Administrators define certificate policies and security parameters using Intune’s SCEP device configuration profile instead of certificate templates. In essence, the SCEP profile functions as the certificate template. With the Intune device configuration profile, administrators can define the following settings.

Certificate Type

The certificate type can be either a user or a device. Intune Cloud PKI can issue certificates for either or both, as required.

Subject Name (User)

The subject name is unimportant for user authentication certificates because the User Principal Name (UPN) defined in the Subject Alternative Name field is used to authenticate the user. In this field, the administrator can use whatever they like. However, it’s common to use the username here. Avoid using the email attribute here because there’s no guarantee that every user will have this defined on the Active Directory (AD) user object.

Subject Name (Device)

Administrators should supply the device’s fully qualified domain name (FQDN) for device authentication certificates in the subject name field. For hybrid Entra joined devices, administrators can use the {{FullyQualifiedDomainName}} variable. For native Entra-joined devices, you can use {{DeviceName}} and append your DNS suffix, for example, {{DeviceName}}.corp.example.net.

Note: Intune supports numerous variables to populate fields for certificates. You can find a list of supported variables in the following locations.

User Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=Manager%20blog%20post.-,User%20certificate%20type,-Use%20the%20text

Device Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=on%20the%20device.-,Device%20certificate%20type,-Format%20options%20for

Subject Alternative Name (User)

The Subject Alternative Name (SAN) field for user authentication certificates should be populated with the User Principal Name (UPN) value. Ensure this value is appropriately configured internally and supports sign-in to AD.

Subject Alternative Name (Device)

The SAN field for device authentication certificates should be populated with the device’s FQDN. Follow the guidance for device subject names covered previously.

Certificate Validity Period

This field allows the administrator to define the certificate’s validity period. The best practice is to limit the lifetime to no more than one year. A shorter lifetime is recommended for certificates not backed by a Trusted Platform Module (TPM).

Key Storage Provider

This value is critical to ensuring integrity for issued user and device authentication certificates. The best practice is to select Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. However, if you must issue certificates to endpoints without a TPM (e.g., legacy devices, virtual machines, etc.), consider a separate profile with a shorter certificate lifetime to limit exposure.

Key Usage

Digital signature and Key encipherment are required for user and device authentication certificates.

Key Size

The 2048-bit key size is the minimum recommended value for certificates with RSA keys. Using 4096-bit is not recommended for end-entity certificates and can potentially cause conflicts in some cases. Intune Cloud PKI does not support the 1024-bit key size.

Hash Algorithm

SHA-2 is the best practice for the hash algorithm. SHA-1 has been deprecated and should not be used.

Root Certificate

Select the Cloud PKI root CA certificate.

Extended Key Usage

The minimum requirement for user and device authentication certificates is Client Authentication (1.3.6.1.5.5.7.3.2).

Renewal Threshold

This value specifies at what point the certificate can be renewed. 20% is commonly used for certificates with a one-year lifetime.

SCEP Server URLs

This value can be found on the configuration properties page of your Cloud PKI issuing CA. The URI will include a variable in the URL. The variable is there by design. Copy and paste this URL exactly as displayed in the SCEP URL field.

Training

Are you interested in learning more about issuing and managing certificates with Microsoft Intune? Would you like to know how to securely and optimally implement PKCS and SCEP infrastructure on-premises? Do you want more details about deploying and managing Microsoft Intune Cloud PKI? Register now for my upcoming three-day live Certificates and Intune Masterclass training event at the ViaMonstra online training academy. We’ll deep-dive into all aspects of certificate management using Intune with on-premises AD CS and Intune Cloud PKI. I’ll be sharing many advanced techniques for adequately securing your certificate infrastructure. Space is limited, so register now!

Additional Information

Mastering Certificates with Intune Training Course

Microsoft Intune Cloud PKI Overview

Microsoft Intune Cloud PKI and Active Directory

Microsoft Intune Certificate Connector Failure

Microsoft Intune Certificate Connector Configuration Failed

Microsoft Intune Certificate Connector Configuration Failure

Microsoft Intune Certificate Connector Service Account and PKCS