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
Related
I have a Blazor Server Application that is invoking a 3rd party API using IHttpClientFactory. When I execute the calling code on my local Windows 11 machine I receive the exception below. However, If I run the same code from an Azure Web App, the API is called successfully.
Error: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
System.Security.Authentication.AuthenticationException: Authentication failed because the remote party sent a TLS alert: '112'.
I have attempted setting the Security protocol to TLS1.2 using the ServicePointManager, however, this does not make a difference. I have run Wireshark to glean some additional information, but all I can see is that my machine is initiating the call with TLS 1.2.
Does anyone have an idea as to why my code works in Azure, but not in my local development environment?
According to the behavior in azure web app, I think the issue should related to environment.
And if you have another os version pc, you can test it, and it should be work normally.
And I found the workaround in win11. You can add the registry key and removed the code to set the protocol to TLS1.2, and the TLS handshake worked from your Windows 11 system.
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!
My servers has been recently upgraded to support TLS 1.2 and rest other (TLS 1.0 and TLS 1.1.) has been disabled. Now when I tries to generate the reference it gives me following exception:
service Url = https://server-name/service.asmx
Error: Cannot obtain Metadata from "service url" If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address. For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata Exchange Error URI: "service url" Metadata contains a reference that cannot be resolved: "service url". An error occurred while making the HTTP request to "service url" This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server. The underlying connection was closed: An unexpected error occurred on a send. Received an unexpected EOF or 0 bytes from the transport stream. HTTP GET Error URI: "service url" There was an error downloading "service url". The underlying connection was closed: An unexpected error occurred on a send. Received an unexpected EOF or 0 bytes from the transport stream.
I tried the solution at following link but didn't worked for me, Kindly help.
support.microsoft.com/kb/888528
We recently ran into this exact issue, after PCI compliance forced us to blanket-disable SSL3 and TLS 1.0. Ultimately, the best solution we found was the same one that client apps are using to allow connectivity to web services on .NET 4.5+; namely, adding some code to adjust that setting for Visual Studio at runtime. In the most basic form, that looks like this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls | System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls12;
We did this via a VS package with a simple configuration UI, which is available in the visual studio gallery, if you want a drop-in solution:
https://visualstudiogallery.msdn.microsoft.com/63750942-1ebe-45dd-bade-552dd850873e
If you'd rather handle it yourself, all you need to do is create a VSIX package or an Add-In (both of which require the visual studio sdk).
Good luck!
I faced the same issue also, i was not able to add service reference in visual studio.
But after installing the Add-In and enabling the TLS1.2 in visual studio, I was able to update the service reference.
Tools -> Security Protocol Manager 2013
https://visualstudiogallery.msdn.microsoft.com/63750942-1ebe-45dd-bade-552dd850873e
I was getting error:
The request was aborted: Could not create SSL/TLS secure channel.
Metadata contains a reference that cannot be resolved:
An error occurred while making the HTTP request to https://...Service.svc.
This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
The underlying connection was closed: An unexpected error occurred on a send.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
This is the follow-up to my original problem: Qt Server+Client App: encryption fails (updated with code)
Also posted this to Qt Forums: http://qt-project.org/forums/viewthread/41293/
Hi,
my goal is establishing two-ways authentication for Server+Client apps. I am having a strange problem however. Using certificates generated by XCA and OpenSSL for testing purposes in my Server+Client apps using Qt 5.2.0.
Note: I do not use QSslSocket::ignoreSslErrors() to get past the errors.
2 scenarios:
1)
Client has valid clientCA, valid local certificate (signed by serverCA, client template) and valid private key set.
Server has valid serverCA, valid local certificate (signed by clientCA, server template) and valid private key set.
2)
Client has valid clientCA.
Server has valid local certificate (signed by clientCA, server template) and valid private key set.
———————-
ad 1)
I can establish secure connection fine but only if I set QSslSocket::peerVerifyMode to VerifyNone on server side (automatically VerifyPeer on the client).
If I do NOT do that I get assigned automatically VerifyPeer mode even though the socket is correctly evaluated as server side (checked SslMode for this). That is apparently contrary to the documentation as it says it should be automatically QueryPeer if the socket is server side. However even setting the socket to QueryPeer manually does not help and the handshake fails the same as with VerifyPeer.
Now the error I get is:
QSslError::CertificateSignatureFailed (4) “The signature of the certificate is invalid”
Inspecting the peer certificate on SSL error (and/or encrypted) on the server reveals that no certificate was presented by the peer (the peerCertificate() yields null certificate) so it is no wonder it fails with this error. I cannot get the peer certificate on client side either in this case.
BUT even if VerifyNone is set on server and encryption succeeds I still get the above mentioned error due to peer (client) not presenting its certificate despite the fact that it should NOT be requested in the first place. On client I can get peer (server) certificate in this case.
———————-
ad 2)
This is documentation style scenario, that should be capable of one way authentication only (client authenticating the server). In this case the peerVerifyMode is again selected as VerifyPeer on server by default.
However peerVerifyMode does NOT have any effect on the handshake on server side! Even when set to VerifyPeer it succeeds despite the fact that client has not presented any certificates.
No matter the setting of peerVerifyMode the error occurs the same as in #1 plus two new errors, therefore I get on server:
QSslError::CertificateSignatureFailed (4) “The signature of the certificate is invalid”
QSslError::UnableToGetLocalIssuerCertificate (11) “The issuer certificate of a locally looked up certificate could not be found”
QSslError::UnableToVerifyFirstCertificate (12) “No certificates could be verified”
Despite these the SSL handshake succeeds regardless of peerVerifyMode on the server side. I get no errors on the client. This once again is contrary to the documentation that clearly states that in case of ANY SSL error the connection is dropped unless they are ignored.
———————————————
I do not understand this behaviour nor how to fix it since I am fairly sure the certificates are ok (the test handshake using the openssl.exe succeeds with verify return code 0 (Ok)). It seems to me that the settings of peerVerifyMode is often ignored though and that in some cases errors are automatically ignored as well. Since they are related to unsent (or not received) peer (client) certificate on the server side I can understand it but not if the peerVerifyMode is set to VerifyPeer.
Can anybody help? Thank you!
I have been able to solve this issue in unusual way. It was caused by bug in Qt, I think this one https://bugreports.qt-project.org/browse/QTBUG-7200 since it matched the symptoms of my latest attempts (same error in Qt while openssl succeeded in verifying the certificates etc.).
Update from 5.2.0 to 5.3.0-beta solved it (bug was apparently solved in 5.2.2).
I am working on integration solution with a payment gateway, we are using SSL3 with digital certificates to secure connection between us, I already reached their services and successfully sent request and received the response.
The problem is when they trying to consume our HTTPs services which hosted on IIS 7 on our Windows 2008 R2 server, they got below error:
**java.io.IOException: java.net.SocketException: Connection reset**
I tried to catch any errors from my-side, so I found this error in "Event Viewer\Windows Logs\System"
**The following fatal alert was generated: 51. The internal error state is 1306**
I think the request is not reached to the service; its dropped some where before the IIS.
Thanks in advance,
Error 51 means there is a problem in the TLS, so please enable TLS 1.0 on the registry and increase logging of the SChannel (to get information, warnings and errors about the connection)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000007
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
http://support.microsoft.com/kb/260729