Error: "TLS handshake error: tls: no cipher suite supported by both client and server" when NATS hosted on Windows Server 2012 R2 - nats.io

I am using NATS messaging server on Windows Server 2012 R2. I have provided the TLS configuration as follows:
authorization {
user: administrator
password: $2a$10$9cVa4WHttwTQDpOnpGP1HuWi44WXTrYvrUO6uWkNlpLPeBFFOnpr6
timeout: 500
}
tls {
cert_file: "C:/NATS/CertFile.pem"
key_file: "C:/NATS/KeyFile.pem"
timeout: 2
}
I am using BCrypt to store password and X509 self-signed certificate. When I run the server on Windows Server 2016, the clients connects successfully while using secure communication. But when I use the NATS server on Windows Server 2012 R2, it give me the an exception in my client application.
Can you please help me out?
Many thanks,
Adeel.
I have tried updating to NATS.Client to v0.9.0.
I set the following property in C# while using NATS.Client API:
NATSConnectionSetting connectionSetting = NATSConnectionSetting.GetDefaultNATSConnectionSetting();
connectionSetting.UseTLS = true;
The exception I am getting in client application logs:
NATS.Client.NATSConnectionException: TLS Authentication error ---> System.AggregateException: One or more errors occurred. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The message received was unexpected or badly formatted
In the NATS server logs I can see:
TLS handshake error: tls: no cipher suite supported by both client and server

Some windows systems can be restrictive as to what cipher suites they support. NATS defaults to only the most secure cipher suites, but does allow for specification of others in the configuration.
Here is a TLS configuration stanza that specifies cipher suites that should work on most windows systems:
tls {
cert_file: "C:/NATS/CertFile.pem"
key_file: "C:/NATS/KeyFile.pem"
cipher_suites: [
"TLS_RSA_WITH_RC4_128_SHA",
"TLS_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_RSA_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_RC4_128_SHA",
"TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
]
}
Another reference can be found in the testing configuration, here. I suggest narrowing the cipher suites down to include only the most secure suites that work in your environment and to avoid RSA if you can. To get a list of all available cipher suites, run nats-server -help_tls. Hope this helps!

Related

Error while connecting exchange server from WCF Service

I am using exchange listener inside wcf service.
Recently we moved the applications to new Server.
we have installed SSL certificate as well in IIS.
we are getting error in ExchangeService.AutodiscoverUrl(string emailAddress) method in new server.
in old server it is working fine.
In the event viewer we are able to see the below error.
An SSL 3.0 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 TLS connection request has failed.
The TLS encryption protocol is not enabled on Windows Server. This may cause the connection failure of applications that connect via HTTPS protocol and TLS encryption.
You can determine which protocols are enabled by viewing the following registry keys:
To enable SSL3.0, please follow the steps below:
Using regedit to add the following keys:
1.Right click on protocols -> new -> key -> "SSL 3.0" then "TLS 1.0"
2.Under each of the keys above you need to create additional keys "Client" and "Server"
3.create DWORD (32bit) value called "Enabled" under each "Client" and "Server" key for "SSL 3.0 and TLS 1.0"
DWORD (32bit) Value
Value name = Enabled
Value date = 0
Value date can be set to "1" - Enabled or "0" – Disabled
4、restart your computer to implement the change

Handshake failure 40 on incoming traffic from telegram to my server

My telegram Bot doesn't receive updates anymore, Because of the last api update Which only works with tls 1.2 .
I tried with wireshark listening to check , I found that the outgoing requests are sent over tls1.2 successfully But the INCOMING ONES (updates,commands sent to my bot) fail due to HANDSHAKE FAILURE.
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
Knowing that i tried :
Enabling Tls 1.2 using Internet Options
Added client and Server Keys to SChanel entry in registry
(DisabledByDefault = 0 ; Enabled = 1)
Installed This Update kb3140245
Installed all the important updates on my windows server 2012
What should i do to solve this issue ?
Thanks for your time.
Note: This is an edited repost of my original answer, as it was deleted for being low-quality.
The issue is that in the TLS1.2 set of cipher suites, the Telegram API only accepts a limited set. Of those only TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) are supported on Windows 2012. A secure channel for SSL / TLS could not be created on create new TelegramBotClient
However Microsoft has disabled their implementations of those ciphers on Windows 2012 already in 2014 as part of a remote code execution patch: MS14-066: Vulnerability in SChannel could allow remote code execution: November 11, 2014
They are considered unsafe ciphers by among others Qualys SSL Labs and NARTAC.
Note that the Telegram API supports many other, more secure ciphers even TLS 1.3, but none of those are supported by any version of Windows 2012. TLS 1.3 is not supported by any Windows version at the time of writing.
In summary, this explains why the problem occurs. The bad news is that there is no good solution on Windows Server 2012. The oldest Windows Server version that supports Telegram bots currently is Windows Server 2016. I'm moving my bot to a Ubuntu 19.10 server.

IdentityServer 4 and TLS 1.2

I have disabled TLS 1.0 and TLS 1.1. in Identity Server (v4 running in a Service Fabric Cluster using WebHostBuilder, targeting .NET 4.6.2 using a self-signed cert). I have added the following in Startup.cs:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
And I receive the following error:
System.InvalidOperationException: IDX10803: Unable to create to obtain
configuration from: 'https://services.mytest.com:8443/oauth/.well-
known/openid-configuration'. ---> System.IO.IOException: Unable to get
document from: https://services.mytest.com:8443/oauth/.well-
known/openid-configuration ---> System.Net.Http.HttpRequestException: An
error occurred while sending the request. ---> System.Net.WebException: The
underlying connection was closed: An unexpected error occurred on a receive.
---> System.ComponentModel.Win32Exception: The client and server cannot
communicate, because they do not possess a common algorithm
I've looked at the questions here:
IDX10803: Unable to create to obtain configuration
Unable to obtain configuration from well-known/openid-configuration
I've tried the suggestions (including adding the cert to trusted root)
I don't know much about that particular piece of software but the problem here is not that the certificate is not trusted (according to the error message) but your server and client try to negotiate during TLS handshake which protocol version, cryptographic ciphers and keyexchange mechanism should be used. It would seem that the client and server have now become incompatible. Either change the client or the server.
See also for an related and post with a possible solution:
The client and server cannot communicate, because they do not possess a common algorithm

Sending mail using javamail api from IBM Websphere Application Server 8

How to send mail using gmail from IBM Websphere Application Server 8 using javamail 1.5.2 api because that give me a same error :
Caused by: java.security.cert.CertPathValidatorException: The certificate issued by OU=Equifax Secure Certificate Authority, O=Equifax, C=US is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error
You need to import Google certificate into the WebSphere's trust store.
WebSphere does not trust the certificate. You are trying to send an email to a server that uses SSL.
The easiest way is to use Retrieve from port
You can find info here: http://www-01.ibm.com/support/knowledgecenter/SS7JFU_8.5.5/com.ibm.websphere.express.doc/ae/usec_sslretrievesignercert.html
Have you used correct values for retrieving?
Host: smtp.gmail.com
Port: 465
Alias: gmail

CA Certificate request failure - The RPC server is unavailable - DCOM was unable to communicate with the computer

I am facing an issue while trying to request user certificate from a Microsoft CA on IIS7/Windows Server 2008 R2.
For requesting certificate, I am using the CCertRequest submit method.
In my logs, I have the following error :
CCertRequest::Submit: The RPC server is unavailable. 0x800706ba (WIN32: 1722) COMException at CERTCLIENTLib.CCertRequestClass.Submit(Int32 Flags, String strRequest, String strAttributes, String strConfig)
and the associated DCOM error in Event Viewer :
DCOM was unable to communicate with the computer
cert.XXX.com/XXXCA using any of the configured
protocols.
When I ping the CA using CertUtil command tools, the command is successfully :
C:\Windows\system32>certutil -ping -config "cert.XXX.com\XXXCA "
Connecting to cert.XXX.com\XXXCA ... Server "XXXCA"
ICertRequest2 interface is alive
CertUtil: -ping command completed successfully.
Do you have any idea to help me ?
I fixed it!
The valid configuration string for the Certificate Services server is
ComputerName\CAName
and not
ComputerName/CAName

Resources