Test connectivity fails Mapi/https
we're using the https://testconnectivity.microsoft.com URL to test external connectivity to our on-prem Exchange 2016 servers. the test failis with MAPI/HTTPS check as follows Looking at the server's event log we found the following error. And running the exchange healthchecker Is it possible that the connectivity test is using an old cypher algorithm or is something wrong in the exchange configuration ?
TLS 1.2 support on SQL server 2014
We have SQL server 2014 (with sp3 installed) hosted on Windows Server 2012 R2. Recently our client application upgraded to use OpenSSL 3.0.8 and we are restricting to use TLSv1.2 & TLSv1.3 only. Now our client application is not able to connect to SQL server via ODBC driver 17/18. I tried enabling TLSv1.2 on SQL server 2014 including applying service pack3 (https://support.microsoft.com/en-us/topic/kb3135244-tls-1-2-support-for-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe), updating host OS, updating .NET on host OS, adding registry entries to Schannel, enabling group policy to use FIPS enabled ciphers, etc. Unfortunately none of these solved the issue. I tried to diagnose the issue with openssl/sslscan utilities, but they are also not able to connect to the server on port 1433. Client waits for 'server hello' during handshake and timeout happens. The Windows/system log shows the errors: 1. 36874 : An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. 2. 36888: A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The windows schannel error state is 1205. Note that, same client can connect to another instance of SQL server 2016 hosted on another server without any issue. Could you please suggest what more configuration we are missing on SQL server 2014?
Server 2019 no "Server Hello" when using TLS_RSA_WITH_AES_ ciphers (TLS1.2) schannel 36874
Hi Hoping someone might have come across something similar as the support forum entries are filled with irrelevant responses and tumbleweed. A recently migrated CA cluster is not sending any TLS conversation completion when the client uses a cipher from the TLS_RSA_WITH_AES_* type (so TLS_RSA_WITH_AES_128_CBC_SHA256 or similar). This also seems to be negatively impacting RPC certificate enrolment from Windows 7 systems. Using Nartac tools and manually (double, triple, quadruple) checking the registry settings myself I can see that the ciphers are present in the list of supported/available ciphers. I can see that TLS1.2 is working. As soon as a client offers TLS_ECDH_* the server responds like an enthusiastic puppy. using TLS_RSA_WITH_AES_ it ignores the traffic (no server hello or attempt to negotiate) and logs Schannel Errors 36874 in the server event log. I have verified this using wireshark on client and server. Whilst these are hosted in azure there shouldn't be any network layer kit interfering with the connection. There is a standard load balancer which single routes all traffic to the active AD CS cluster node. No inspection or TLS termination should be occurring. There are no GPOs controlling anything to do with TLS or communication security (checked with gpresult and gpmc, along with repeated verification of the registry settings) has anyone seen anything like this before? yes I have been through the enabling TLS 1.2 articles a bajillion times and know where to enable TLS 1.2 for both schannel and .net In need of more straws to clutch at.
