Share via

SQL AlwaysOn - SSL encryption error from local address

Rives, Vincent 1 Reputation point
2021-08-10T14:43:19.187+00:00

Hi

In our 2-nodes SQL Cluster configured with AlwaysOn Groups (AAG), the SQL log shows the following error every second:

Encryption is required to connect to this server but the client library does not support encryption; the connection has been closed. Please upgrade your client library. [CLIENT: 169.254.2.86]

The AlwaysOn Groups work well.
The SSL Certificate is configured on the 2 nodes with the listener name in the certificate alternate name.
In SQL Server Configuration Manager the parameter "Force Encryption" is set to Yes

The sessions are all encrypted except for the SQL Mirroring between the 2 nodes:
SELECT encrypt_option,protocol_type
FROM sys.dm_exec_connections
TRUE TSQL
TRUE TSQL
TRUE TSQL
FALSE Database Mirroring
TRUE TSQL
FALSE Database Mirroring
TRUE TSQL
TRUE TSQL

With SQL Profiler I failed to identify what client with local address 169.254.2.86 is trying to connect to the instance SQL.

Thanks for your help!

SQL Server
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
13,364 questions
0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Cris Zhan-MSFT 6,616 Reputation points
    2021-08-11T03:36:39.64+00:00

    Hi,

    Welcome to Microsoft Q&A!

    This error seems to indicate that there is a client that does not support encryption and then cannot connect to the server. According to the IP address(local), it seems that the connection is from the local. Please confirm whether this error only appears in the error log of the primary replica of the availability group.

    Please check if you get this error message when connecting to this availability group using SSMS locally, and check whether there is any relevant information recorded in the Windows logs.

    0 comments
  2. Rives, Vincent 1 Reputation point
    2021-08-11T21:41:12.577+00:00

    Hi
    Thanks for your response.

    1. I confirm that the error only appears in the error log of the primary replica of the AG but not on the secondary replica.
    2. Instead of using SSMS to connect remotely to the SQL instance, I first connected to the primary server (VM) via RDP then connect using the local SSMS. I still see the error message every minute in the error log.
    3. in my RDP connection, I ran an ipconfig /all and found that the local IP address corresponds to : Tunnel adapter Local Area Connection* 1: Connection-specific DNS Suffix . :
      Description . . . . . . . . . . . : Microsoft Failover Cluster Virtual Adapter
      Physical Address. . . . . . . . . : 02-D6-A3-21-AE-41
      DHCP Enabled. . . . . . . . . . . : No
      Autoconfiguration Enabled . . . . : Yes
      Link-local IPv6 Address . . . . . : fe80::8df8:b53c:390c:1a4a%9(Preferred)
      IPv4 Address. . . . . . . . . . . : 169.254.2.86(Preferred)
      Subnet Mask . . . . . . . . . . . : 255.255.0.0
      Default Gateway . . . . . . . . . :
      DHCPv6 IAID . . . . . . . . . . . : 167935077
      DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-17-88-5C-00-50-56-88-92-23
      NetBIOS over Tcpip. . . . . . . . : Enabled
      1. In the Windows Event Log, I found in the Application Logs the same Encyption error messages as in the SQL Error log but nothing else.

    Conclusion:
    The client that trying to connect is a Cluster Virtual interface. How to deal with that?

    Thanks for your precious help!

  3. Rives, Vincent 1 Reputation point
    2021-08-13T03:10:24.477+00:00

    Hi

    1. Yesterday the infra team pushed Windows patch on the primary nodes which triggered a failover. The new primary replica (the previous secondary) does not have the encryption errors but the new secondary replica (the previous primary) still has the encryption errors.
      So the problem seems to be only on my first node.
    2. As suggested I disabled the "Forced Encryption" only on the first node. I no more have Encryption errors but I have other errors:
      122897-image.png

    "SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. “
    AND
    "Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. [CLIENT: 169.254.2.215]"

    The Cluster works well so I am not sure why the FailoverCluster VIrtual interface could have problem with Login authentication....

    Thanks a lot for your help again.

    0 comments
  4. Rives, Vincent 1 Reputation point
    2021-08-18T18:49:16.75+00:00

    Hi,

    The new SSPI errors i had got after disabling "Forced Encryption" did not remain. After a few minutes, they were not coming back.
    The InfraTeam pushed the usual monthly windows updates so the 2 nodes were rebooted.
    So today I re-enabled the "Forced Encryption" on the primary node Configuration Manager then failover the AAGroup to the secondary, restarted the SQL service on the primary, then failed back the AAG Group.
    I don't have the errors anymore.
    So the problem seems to be fixed now.

    FYI - With a SELECT on the table sysprocesses I see that the processes/sessions coming from the local physical address of the "Microsoft Failover Cluster Virtual Adapter" are multiples session SQL from the SQL Agent (including database mail) and one session from Microsoft Windows Operating System which run SP_SERVER_DIAGNOSTIC_SLEEP. So the encryption errors where probably coming from these 2 sources.

    Thanks for your valuable help!

    Vincent

    0 comments