Join me and the CertKit team on Tuesday, October 6, 2026, at 9:00 AM PDT for a free, live webinar about the upcoming reduction in public TLS certificate lifetimes. Beginning March 15, 2027, the maximum validity period for public TLS certificates will be reduced to 100 days. This change will make manual certificate management increasingly difficult for many organizations.
Automation
Shorter certificate lifetimes require organizations to identify, enroll, deploy, and renew certificates more frequently. Automation can help reduce the administrative effort and the risk of service interruptions caused by expired certificates. This is especially important for public-facing Microsoft workloads such as Internet Information Services (IIS), Remote Desktop Services (RDS), Always On VPN, DirectAccess, and other services that use public TLS certificates.
Visibility
Effective certificate management begins with knowing which certificates exist, where they are installed, and when they expire. Without this visibility, organizations may overlook certificates until they are close to expiration or have already expired.
Internal Certificates
Certificates issued by a private certification authority (CA) aren’t subject to the lifetime restrictions imposed on public TLS certificates. However, they still require inventory, monitoring, and renewal. A consistent approach to managing public and private certificates can help reduce operational overhead.
How CertKit Helps
CertKit is a cloud-based service for managing public and private TLS certificates. During the webinar, we’ll demonstrate how CertKit provides visibility into certificate inventories and expiration dates while automating common lifecycle tasks such as enrollment, deployment, and renewal. We’ll also review recent additions to the service.
Register Now
The webinar takes place on Tuesday, October 6, at 9:00 AM PDT. Registration is required. Everyone who registers will be notified when the session recording is available.
CertKit is a cloud-based solution that automates the issuance and management of public TLS certificates. It also provides certificate monitoring and alerting for public-facing workloads. However, many organizations have internal (non-public-facing) services that also use TLS. CertKit agent v1.13.0, currently in preview, closes this gap by providing visibility into TLS certificates used by intranet resources. After installing the latest release of the agent, CertKit can now provide visibility into the status of TLS certificates for internal resources.
Intranet Monitoring
After installing or updating the CertKit agent to v1.13.0, administrators can select an internal TLS service to monitor. Follow the steps below to enable this feature.
Certificate Collection
I recommend creating a separate Certificate Collection to support intranet monitoring. In the CertKit management console, click Add Collection, enter a unique, descriptive name, and click Add Collection.
Install the Agent
Once the new collection is created, navigate to the Agents tab, select your platform, then download, install, and register the agent.
Monitor New Host
After the agent is installed and registered, navigate to the Monitoring tab and click Monitor New Host. Enter the fully qualified domain name (FQDN) of the resource and specify its TLS port. Under Host Visibility, select Internal, and then choose the agent to monitor the host from. When finished, click Monitor Host.
Note: The server running the CertKit agent does not require a TLS certificate of its own to monitor internal resources.
Monitored Hosts
CertKit can track certificates for any internal workload that uses TLS. In this example, the monitored resources include web applications, security appliances, load balancers, and HTTP CRL distribution points. The list also includes LDAPS on the domain controllers and the RDP and WinRM HTTPS services on the management workstation.
The circle next to each resource indicates its certificate status. Green indicates a healthy certificate, yellow indicates one approaching expiration, and red indicates an expired certificate or another detected issue.
Note: The RDP certificate on the management workstation appears red because it contains only the Remote Desktop Authentication EKU (1.3.6.1.4.1.311.54.1.2). It intentionally does not include Server Authentication, which CertKit currently expects when validating the service. CertKit is aware of this limitation and plans to address it in a future release.
Host Discovery
CertKit provides robust discovery for public websites but does not currently offer equivalent functionality for intranet resources. Administrators can identify internal systems listening on a specific port by using Nmap.
nmap.exe -Pn -p [port] --open [internal subnet]
For example:
nmap.exe -Pn -p 443 --open 172.16.0.0/24
Alternatively, add the -oX switch to save the output in XML format.
The resulting Nmap XML file output can be converted to CSV format using this PowerShell code.
Summary
CertKit agent v1.13.0 extends certificate monitoring to internal TLS services, giving administrators greater visibility into certificates that were previously difficult to track. Although intranet host discovery remains a manual process, tools such as Nmap and PowerShell can help identify resources to add to the monitoring platform
Getting Started with CertKit
Need help improving certificate visibility and management across your organization? Want to automate public TLS certificate enrollment for workloads such as DirectAccess, Always On VPN, IIS, SQL, and more? I can help you assess your certificate environment, identify monitoring gaps, and develop a strategy for managing certificates across internal and public-facing workloads. Fill out the form below, and I’ll provide you with more information.
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.
Right-click the default Web Server template and choose Duplicate Template.
Select the Compatibility tab.
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.
Select Windows 10/Windows Server 2016 from the Certificate recipient drop-down list.
Select the General tab.
Enter a descriptive name in the Template display name field.
Select a validity period of 1 year with a renewal period of 6 weeks.
Select the Cryptography tab.
Select Key Storage Provider from the Provider Category drop-down list.
Select RSA from the Algorithm name drop-down list.
Enter 2048 in the Minimum key size field.
Select SHA256 from the Request hash drop-down list.
Select the Issuance Requirements tab.
Check the box next to CA certificate manager approval.
Select the Subject Name tab.
Select Supply in the request.
Select the Extensions tab.
Select Application Policies.
Ensure that Server Authentication is the only application policy listed.
Select the Security tab.
Click Add.
Grant Read and Enroll permissions to the SQL Server security group or the SQL server’s computer account.
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.
Right-click on the Personal folder and choose All Tasks > Request New Certificate.
Click Next.
Click Next.
Check the box next to the SQL server certificate template.
Click the More information is required to enroll for this certificate. Click here to configure settings link.
Select the Subject tab.
In the Subject Name section, select Common Name from the Type drop-down list.
Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
Click Add.
In the Alternative name section, select DNS from the Type drop-down list.
Enter the SQL server’s fully qualified domain name (FQDN) or the alias name of the SQL cluster in the Value field.
Click Add.
[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.
Click Add.
Click Ok.
Click Enroll. The status should indicate that enrollment is pending.
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.
Expand the CA.
Select Pending Requests.
Note the request ID for the pending request. After approval, the request ID will be required later to retrieve the certificate.
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.
Enter certreq.exe -retrieve <request ID>.
Select the CA where the certificate was issued.
Click Ok.
Select a location and enter a name for the file in the File name field.
Click Save.
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.
Right-click the SQL server certificate and choose All Tasks > Manage Private Keys.
Click Add.
Enter the name of the SQL server domain service account and click Check Names.
If using the default SQL server service account, perform the following steps.
Click on Locations.
Select the local server.
Click Ok.
Enter NT Service\MSSQLSERVER and click Check Names.
Click Ok.
Uncheck Full control. The only permission required is Read.
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.
Expand SQL Server Network Configuration.
Right-click Protocols for MSSQLSERVER and choose Properties.
Select the Certificate tab.
Select the new certificate from the Certificate drop-down list.
Select the Flags tab.
Select Yes next to Force Strict Encryption.
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.
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.
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 Encryption
Encourages but does not require encryption. Unencrypted connections may still be allowed.
Force Strict Encryption
Requires 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.
Microsoft Always On VPN provides seamless and transparent remote access to corporate applications and data. In most cases, accessing resources over the VPN works the same as on-premises. However, a few folks have asked recently about an issue they found when using the SQL Server Management Studio (SMSS) to connect to a remote SQL server over Always On VPN.
Principal Name Incorrect
Administrators may encounter the following error message when using SMSS to connect to Microsoft SQL servers over an Always On VPN connection.
“The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server)”
Resolution
There are a few different ways to resolve this issue. Choose the option that works best in your environment.
VPN Configuration
For Always On VPN deployments with Windows 11 24H2 and later clients, add the following setting to your XML configuration file.
<UseRasCredentials>false</UseRasCredentials>
For clients older than Windows 11 24H2, you must edit the rasphone.pbk file setting as follows.
UseRasCredentials=0
Group Policy
Optionally, a Group Policy Object (GPO) can be created and applied to target endpoints. For testing, you can enable this setting using the local group policy editor (gpedit.msc). Using either method, enable the following group policy setting.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication = Enabled
Registry Editor
This method can be used for local testing. Open the Windows Registry Editor (regedit.exe) on a test client and create the following entry.
Key = HKLM\SYSTEM\CurrentControlSet\Control\Lsa Name = DisableDomainCreds Type = DWORD Value = 1
PowerShell
The following PowerShell command will also create the required registry entry. Administrators can run the command interactively or deploy it via automation.
Recently I wrote about an issue with DirectAccess servers exhibiting high SQL Server CPU usage. In that article I demonstrated a way to resolve the issue by adding a crucial index to a table in the remote access inbox accounting database. The process was a bit involved and required downloading third-party tools to make configuration changes on the DirectAccess server.
Going forward, making these changes will now be much easier. Microsoft has published guidance for optimizing the remote access inbox accounting database using PowerShell. They’ve also provided scripts to back up the database and to confirm that optimization has been implemented.
For more information and to download the remote access inbox accounting database optimization PowerShell scripts, click here.
UPDATE – March 14, 2016: Microsoft has published official guidance for implementing the changes outlined in this article using PowerShell. Details here.
Introduction
RADIUS and Inbox accounting are the two supported logging options for DirectAccess in Windows Server 2012 R2. When Inbox accounting is selected, a Windows Internal Database (WID) is provisioned. Part of the base operating system, WID is functionally similar to SQL Server Express.
SQL Server Utilization Issues
Over the last few months I’ve had a few customers reach out to me with a peculiar performance issue. For customers with very busy DirectAccess servers, where those servers have also been configured to use Inbox accounting, they’ve reported observing unusually high CPU utilization on the sqlservr.exe process.
Image courtesy Thomas Vuylsteke. Used with permission. – setspn.blogspot.com
As luck would have it, Thomas Vuylsteke, a Microsoft Platforms Premiere Field Engineer (PFE), had already identified the issue and a workaround. Thomas traced the source of high CPU utilization on the sqlservr.exe process to a missing index on a session state table in the DirectAccess accounting database. If you are interested in learning how he performed the troubleshooting to identify and resolve this problem, you can read his entire blog post here.
Resolution
To resolve this issue, create an index on the Session Table in the DirectAccess database. Changes to WID must be made locally, as it is not remotely manageable. WID does not include a management interface, which means the SQL Server management tools would normally have to be installed. However, I’m not a fan of installing any extraneous software on the DirectAccess server, so thankfully one of the readers of Thomas’ excellent article on this subject, Fredrik Elmqvist, provided a very helpful alternative. Fredrik suggesting using the HeidiSQL tool, for which a fully portable version exists. This allows for changes to be made to the WID database without having to install any additional software.
Changes to WID
Begin by downloading the portable version of HeidiSQL here. Next, log on to the DirectAccess server as the local administrator. It is crucial that you must be the local administrator, not just a local or domain user with local administrator privileges. Extract the files from the download and copy them to the DirectAccess server, then follow these steps:
Double-click heideisql.exe to launch the management tool.
Click on New and then for the Network Type select Microsoft SQL Server (named pipe).
For the Hostname / IP: enter \\.\pipe\MICROSOFT##WID\tsql\query.
Select the option to Use Windows Authentication.
Click Open to continue.
Click the Query tab in the center console window and enter the following commands: Use RaAcctDb
Create NonClustered Index IdxSessionTblSessionState on SessionTable (SessionState,ConnectionID)
Click the Run icon in the tool bar or press F9. This will execute the code and create the missing index on the Session Table in the DirectAccess database.
Confirm the index was created by clearing the previous query or creating a new query and then entering the following commands: select * from sys.indexes where name like ‘idx%’ order by name asc
Summary
Once the change has been made, sqlservr.exe CPU utilization should return to normal. If you have multiple DirectAccess servers configured in a load-balanced array or in a multisite configuration, be sure to repeat these steps on each DirectAccess server in the organization.
Recently I wrote about an issue with 
RADIUS and Inbox accounting are the two supported logging options for DirectAccess in Windows Server 2012 R2. When Inbox accounting is selected, a 
