Troubleshooting SSL_PE_NO_CIPHER Error in SQL Server at Endpoint 5022

Table of Contents

Encountering an SSL_PE_NO_CIPHER error in SQL Server, particularly at endpoint 5022, signifies a critical communication breakdown. This error typically indicates that the client and server failed to agree on a common encryption algorithm (cipher suite) or a compatible Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol version during the handshake process. Endpoint 5022 is frequently associated with SQL Server features like Database Mirroring or AlwaysOn Availability Groups, where secure communication is paramount. Resolving this issue is vital for maintaining the integrity and availability of your SQL Server instances and their high-availability solutions.

This guide will walk you through the necessary steps to diagnose and rectify the SSL_PE_NO_CIPHER error. We will focus on ensuring that your SQL Server environment, along with its underlying operating system and .NET Framework components, is configured to utilize modern and secure TLS protocols and compatible cipher suites. Ignoring these configuration discrepancies can lead to persistent connectivity problems and potential security vulnerabilities, compromising your data’s protection.

Understanding the SSL_PE_NO_CIPHER Error¶

The SSL_PE_NO_CIPHER error message is a low-level indication that the SSL/TLS handshake failed because neither side could propose or accept a mutually supported cipher suite. In simpler terms, it’s like two parties trying to speak, but they don’t share any common languages. For secure communication to be established, both the client initiating the connection and the SQL Server instance acting as the server must agree on a specific protocol version (e.g., TLS 1.2) and a strong set of cryptographic algorithms (a cipher suite) for encryption, authentication, and key exchange.

Several factors can contribute to this problem, including outdated operating system patches, misconfigured registry settings, or strict security policies that disable older, less secure protocols without enabling newer ones. Often, organizations disable older protocols like TLS 1.0 or TLS 1.1 due to security compliance requirements, but fail to ensure that TLS 1.2 or higher is properly enabled and configured across all relevant system components. This imbalance creates a communication gap that manifests as the SSL_PE_NO_CIPHER error, preventing secure connections from being established to SQL Server.

Verifying and Enforcing SSL/TLS Protocol Versions¶

The first crucial step in resolving the SSL_PE_NO_CIPHER error is to confirm that both the client and the SQL Server host support and are configured to use compatible SSL/TLS protocol versions. Modern security standards mandate the use of TLS 1.2 or newer, as older versions like TLS 1.0 and TLS 1.1 have known vulnerabilities. If your servers are not explicitly configured for TLS 1.2, or if components like the .NET Framework are using older defaults, you will encounter handshake failures.

The following PowerShell scripts are designed to enforce TLS 1.2 usage across various critical components of the Windows operating system and the .NET Framework. These changes modify the system registry to ensure that applications using these frameworks prioritize or exclusively use TLS 1.2 for secure communications. It’s imperative to back up your registry before making any modifications and to perform these changes in a controlled environment.

Enforcing TLS 1.2 for .NET Framework¶

The .NET Framework is widely used by SQL Server components and client applications for establishing secure connections. Ensuring it defaults to TLS 1.2 is critical. The scripts below configure specific registry keys for different versions and architectures of the .NET Framework, promoting stronger cryptography and default TLS versions.

.NET Framework v2.0.50727¶

This section targets the .NET Framework version 2.0.50727, which might still be present on some systems supporting older applications. The commands create the necessary registry path if it doesn’t exist and then set three important properties. AspNetEnforceViewStateMac enhances security for ASP.NET applications, while SystemDefaultTlsVersions and SchUseStrongCrypto instruct the framework to use default TLS versions provided by the operating system and to employ strong cryptographic algorithms, respectively.

# .NET Framework v2.0.50727
New-Item -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "AspNetEnforceViewStateMac" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1

These settings collectively push applications relying on this specific .NET Framework version to leverage the most secure TLS protocols available on the system. This is crucial for preventing scenarios where an older framework might attempt to negotiate an outdated protocol, leading to the SSL_PE_NO_CIPHER error.

.NET Framework v4.0.30319¶

Similarly, for .NET Framework version 4.0.30319, which is more commonly found on modern Windows systems, the same principles apply. These registry modifications ensure that applications utilizing this version also adhere to current security standards by defaulting to system-defined TLS versions and using strong cryptographic practices. This consistency across different framework versions is key to a robust security posture.

# .NET Framework v4.0.30319
New-Item -Path "HKLM:\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319" -Name "AspNetEnforceViewStateMac" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1

By explicitly setting SystemDefaultTlsVersions and SchUseStrongCrypto to 1 (true), you are overriding potential default behaviors that might lean towards less secure options. This proactive configuration significantly reduces the likelihood of SSL_PE_NO_CIPHER errors arising from framework-level protocol mismatches.

Wow6432Node for .NET Framework (64-bit Systems)¶

On 64-bit Windows operating systems, applications can run in both 32-bit and 64-bit modes. The Wow6432Node path in the registry is used to store 32-bit application settings when running on a 64-bit OS. To ensure comprehensive coverage, it’s essential to apply the same TLS 1.2 enforcement settings to the 32-bit view of the registry for .NET Framework versions.

Wow6432Node for v2.0.50727¶

# Wow6432Node\Microsoft\.NETFramework\v2.0.50727
New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "AspNetEnforceViewStateMac" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1

This ensures that any 32-bit applications on a 64-bit system that might be interacting with SQL Server and using this .NET Framework version are also configured for robust TLS 1.2 communication. Overlooking this detail can lead to persistent issues for specific client applications.

Wow6432Node for v4.0.30319¶

# Wow6432Node\Microsoft\.NETFramework\v4.0.30319
New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "AspNetEnforceViewStateMac" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1

Applying these settings to the 32-bit registry path for .NET Framework 4.0.30319 ensures that all dependent components, regardless of their architecture, consistently seek to establish secure connections using modern TLS protocols. This holistic approach prevents blind spots in your security configuration.

Enforcing TLS 1.2 for WinHTTP¶

WinHTTP (Windows HTTP Services) is a low-level HTTP client API used by many Windows applications and services, including some SQL Server components and client tools. Explicitly configuring WinHTTP to prefer TLS 1.2 is another critical step to prevent communication failures. The DefaultSecureProtocols registry setting controls which secure protocols WinHTTP will attempt to use.

WinHTTP (64-bit)¶

The following script configures the main WinHTTP settings for TLS 1.2. The value 0x00000800 corresponds specifically to TLS 1.2. By setting this, you instruct WinHTTP to use TLS 1.2 when negotiating secure connections.

# WinHTTP
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value 0x00000800

This is an essential setting for ensuring that services and applications relying on WinHTTP can successfully establish secure connections using the modern TLS 1.2 protocol. Without this, they might fall back to older, disabled protocols, leading to connection failures.

Wow6432Node for WinHTTP (32-bit on 64-bit Systems)¶

Just like with the .NET Framework, the Wow6432Node path needs to be addressed for WinHTTP settings on 64-bit systems to ensure 32-bit applications are also covered. This guarantees that all applications, irrespective of their bitness, use TLS 1.2 for WinHTTP communications.

# Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value 0x00000800

Applying this change ensures that any 32-bit application using WinHTTP on a 64-bit server can correctly negotiate TLS 1.2, preventing potential SSL_PE_NO_CIPHER errors from such components.

Restart Required¶

After applying any of these registry changes, it is critical to restart the server. These settings are often loaded at system startup or when services are initiated. A restart ensures that all services, including SQL Server and its dependent components, pick up the new TLS configuration. Without a restart, the changes might not take effect, and the SSL_PE_NO_CIPHER error could persist.

Disabling Older TLS Protocols for Enhanced Security¶

While enforcing TLS 1.2 is crucial, equally important is the explicit disabling of older, less secure TLS/SSL protocols. Protocols like TLS 1.0 and TLS 1.1 are considered insecure due to various vulnerabilities and are no longer compliant with many industry security standards, such as PCI DSS. Leaving them enabled can expose your SQL Server to potential attacks, even if TLS 1.2 is also enabled. Explicitly disabling them removes any ambiguity and forces all communications to use the most secure available protocol.

The following PowerShell script meticulously disables TLS 1.1 and TLS 1.0 for both client and server roles. This ensures that your system will neither initiate connections nor accept connections using these deprecated protocols.

Disabling TLS 1.1¶

This section of the script targets TLS 1.1, disabling it for both inbound (Server) and outbound (Client) connections. The DisabledByDefault and Enabled registry values are set to 1 and 0 respectively, which effectively turns off TLS 1.1.

# Disable TLS 1.1
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Name "DisabledByDefault" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Name "Enabled" -Value 0

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Name "DisabledByDefault" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Name "Enabled" -Value 0

By explicitly setting DisabledByDefault to 1 and Enabled to 0, you ensure that the system’s SCHANNEL (Secure Channel) security provider will not allow TLS 1.1 to be used. This prevents any attempts to fall back to a less secure protocol if a TLS 1.2 negotiation fails for other reasons, thus hardening your SQL Server environment.

Disabling TLS 1.0¶

Similarly, TLS 1.0 is targeted for complete disablement. This is an even older protocol than TLS 1.1 and is considered highly vulnerable. Eliminating its support is a critical step in modern security compliance and best practices.

# Disable TLS 1.0
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Name "DisabledByDefault" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Name "Enabled" -Value 0

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Name "DisabledByDefault" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Name "Enabled" -Value 0

Completely disabling TLS 1.0 reinforces the security posture of your server. After these modifications and a server restart, any client attempting to connect via TLS 1.0 or TLS 1.1 will be rejected, forcing them to use TLS 1.2 or higher, which should resolve the SSL_PE_NO_CIPHER error by eliminating protocol version mismatches for older, insecure protocols.

Additional Troubleshooting and Considerations¶

Even after enforcing TLS 1.2 and disabling older protocols, the SSL_PE_NO_CIPHER error might occasionally persist. This often points to other underlying issues related to the cryptographic handshake. A thorough troubleshooting approach involves examining various layers of your system’s security configuration.

Cipher Suite Order¶

The SSL_PE_NO_CIPHER error explicitly mentions “NO CIPHER,” meaning a suitable cipher suite could not be agreed upon. Even if TLS 1.2 is enabled, the specific list of cipher suites offered by the client and accepted by the server might not overlap. Windows maintains a default cipher suite order, but it can be customized.

• Check Cipher Suite Order: Use Get-TlsCipherSuite in PowerShell to see the current order.
• Modify Order (if necessary): If the client and server support different cipher suites, you may need to adjust the order or add missing suites. This is typically done via Group Policy (Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order) or directly through certutil -setreg chain\ChainsFilter <string>. Ensure that strong, modern cipher suites (e.g., those using AES256-GCM, SHA384) are present and prioritized. A common issue is a client that expects a specific cipher suite that the server either doesn’t support or has de-prioritized.

Certificate Issues¶

While the error explicitly points to cipher negotiation, certificate problems can indirectly contribute. An invalid or improperly configured SSL certificate on the SQL Server can cause the entire TLS handshake to fail before cipher negotiation is completed.

• Certificate Expiration: Ensure the SQL Server’s SSL certificate is valid and not expired.
• Trusted Root: Verify that the certificate is issued by a trusted Certificate Authority (CA) and that the client trusts this CA.
• Subject Name Mismatch: The certificate’s subject name or subject alternative names (SANs) must match the fully qualified domain name (FQDN) used by clients to connect to SQL Server.
• Private Key Permissions: The SQL Server service account must have read permissions to the private key of the certificate.

You can inspect the certificate bound to SQL Server using SQL Server Configuration Manager under SQL Server Network Configuration -> Protocols for MSSQLSERVER -> Certificates tab.

Firewall Configuration¶

Endpoint 5022 is typically used for specific SQL Server services like mirroring or AlwaysOn. Ensure that firewalls (Windows Firewall on both client and server, and any network firewalls) are not blocking traffic on this port. If the initial TCP handshake cannot complete, the SSL/TLS handshake will never even begin. Verify inbound and outbound rules for port 5022 on both the server and any intermediate network devices.

SQL Server Configuration for SSL¶

Double-check that SQL Server is configured to force encryption (if desired) and is correctly using the intended certificate.
1. Open SQL Server Configuration Manager.
2. Navigate to SQL Server Network Configuration > Protocols for .
3. Right-click on Protocols for and select Properties.
4. On the Certificates tab, ensure the correct certificate is selected from the dropdown menu.
5. On the Flags tab, set Force Encryption to Yes if all connections must be encrypted.

Client Application Configuration¶

The client application connecting to SQL Server must also be configured to support TLS 1.2 and strong cryptography.
* Connection String: Ensure the connection string for the client application explicitly requests encryption if the server forces it. For example, Encrypt=True;TrustServerCertificate=False;.
* Driver Version: Use up-to-date database drivers (e.g., ODBC, OLE DB, JDBC, .NET Data Provider) that fully support TLS 1.2. Older drivers might not be compatible.
* Application Framework: If the client application uses .NET Framework, ensure that its underlying framework is configured with the TLS 1.2 enforcement settings as discussed earlier.

Event Logs¶

The Windows Event Viewer is an invaluable resource for troubleshooting.
* System Logs: Look for SCHANNEL errors or warnings (Event ID 36871, 36888, 36868, etc.) which directly relate to SSL/TLS handshake failures. These events often provide specific reasons for the failure, such as “No common cipher suite” or “No common protocol.”
* Application Logs: Check for errors from SQL Server or the client application itself that might provide more context.
* SQL Server Logs: SQL Server’s error log can provide details on connection attempts and failures.

Network Trace (Wireshark)¶

For advanced diagnostics, a network packet capture tool like Wireshark can provide a deep insight into the TLS handshake process. By analyzing the “Client Hello” and “Server Hello” messages, you can determine which TLS protocols and cipher suites are being offered and accepted (or rejected) by both sides. This can pinpoint exactly where the negotiation is failing.

Summary of Troubleshooting Steps¶

To summarize the comprehensive approach to resolving the SSL_PE_NO_CIPHER error, consider the following systematic steps:

1. Backup Registry: Always back up your registry before making any changes.
2. Enforce TLS 1.2 on .NET Framework and WinHTTP: Apply all the PowerShell scripts for both 32-bit and 64-bit registry paths, ensuring SystemDefaultTlsVersions, SchUseStrongCrypto, and DefaultSecureProtocols are correctly set for TLS 1.2.
3. Disable TLS 1.0 and TLS 1.1: Execute the PowerShell scripts to explicitly disable these older, insecure protocols on both client and server roles.
4. Restart Server: Perform a full server restart to ensure all registry changes are applied.
5. Verify Certificate: Confirm the SQL Server certificate is valid, trusted, and correctly assigned, with appropriate private key permissions.
6. Check Firewall: Ensure port 5022 (and 1433 if applicable) is open on all relevant firewalls.
7. Review Cipher Suite Order: If issues persist, investigate and potentially reorder or add cipher suites via Group Policy to ensure a common, strong suite is available.
8. Client Configuration: Ensure client applications use modern drivers and are configured for TLS 1.2.
9. Monitor Event Logs: Continuously check System, Application, and SQL Server logs for further diagnostic information.
10. Network Analysis: Utilize tools like Wireshark for detailed packet-level troubleshooting if all else fails.

This methodical approach tackles the problem from the operating system level, ensuring that the fundamental components supporting SQL Server communications are aligned with modern security practices. By systematically addressing protocol versions, cipher suites, and underlying system configurations, you can effectively eliminate the SSL_PE_NO_CIPHER error and establish robust, secure connections to your SQL Server instances.

Conclusion¶

The SSL_PE_NO_CIPHER error in SQL Server, particularly for endpoint 5022, is a clear indicator that your secure communication settings require immediate attention. By diligently following the steps outlined in this guide – enforcing TLS 1.2, disabling deprecated protocols, and addressing potential issues with certificates, firewalls, and cipher suite order – you can restore secure connectivity and enhance the overall security posture of your SQL Server environment.

Ensuring that your systems adhere to modern cryptographic standards is not just about troubleshooting an error; it’s a fundamental aspect of data protection and compliance. Proactive maintenance and a thorough understanding of your system’s TLS configuration are paramount in today’s threat landscape.

Have you encountered this error before? What specific steps or tools helped you resolve it? Share your experiences and insights in the comments below to help others who might be facing similar challenges.