I have used an external api which can be accessible via https (sha1 ssl), And now the external api system upgraded to sha2. While I am hitting the api, i am getting below exception.
Connecting to test.demo.com|10.200.100.101|:8443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish `SSL connection`.
Update:
Comments from external api team (earlier we used SSL protocol and now TLS (TLSv1.2) is benign used in new setup (SSL was expired protocol)).
Based on description above (without actual code snippet) you need to check if you client application has appropriate protocol specified (if they changed it on server to TLS v1.2, you need to change it in your client as well). Great link regarding different TLS versions.
Related
I'm working with an old legacy app at work that's written in ASP.NET 4. We recently started migrating to the cloud and we had to expose one of the endpoints so that our api gateway (Apigee) can call it. What is the correct way to restrict this endpoint so that it only allows calls from Apigee? I'm aware 2-way-ssl should solve this issue but that requires changes on the Apigee side and we don't have control over that. Is there something I can do on the API side to confirm that the certificate in the request is specifically from Apigee?
You're describing the need for what is sometimes called 'southbound' authentication. Specifically mutual-TLS sometimes called client authentication, as opposed to standard (or one-way) TLS where only the server is being authenticated by the calling client. You're right: mTLS (a.k.a., "two-way SSL") is one means to allow your back-end server to authenticate the calling Apigee-layer 'client'.
When you want client authentication via TLS (mTLS) you need to configure your back-end server endpoint to require mTLS at the time of the handshake, and to have stored in its Truststore the signing CA certificate of the client certificate you expect to see offered up by the calling client at time of connection. Done right, your server
requires mTLS and shuts down the handshake if the client won't
offer a client cert,
validates the client cert is authentic as being issued by a recognized signing CA (Truststore), and
is the actual client cert expected to be seen (e.g., by matching the expected distinguished name).
Here's an authoritative support-community article about doing all this, within Apigee: https://community.apigee.com/questions/63337/mutual-tls-between-client-to-edge-and-edge-to-back.html
From my understanding, each browser implement tls/ssl themself, which mean when user open a https website from a browser, the browser is responsible for encrypt the request.
So is it possible to make a browser or any other type of client that doesn't implement tls/ssl and therefore will make https without encryption? And if yes, then how ?
... client that doesn't implement tls/ssl and therefore will make https without encryption?
HTTPS is HTTP inside a TLS connection. This means a client which does not implement SSL/TLS will not be able to make a HTTPS connection in the first place by the very definition of what HTTPS is.
It might in theory be possible though that TLS is used without encryption, i.e. only with authentication and integrity check. Up to TLS version 1.2 there were the NULL ciphers which made this possible. In practice no sane server will implement this. If the client still tries to use such cipher the TLS handshake will fail since there is no common cipher between client and server.
See also Unencrypted SSL protocol?.
I have seen many implementations of certificate pinning for HTTPS connections originated from client-side apps running on mobile devices using native libraries and plugins.
I would like to know whether such certificate pinning implementations are available for websockets. In the client side (say a mobile device or web browser), can we actually implement certificate pinning for websockets?
If such approach is available, it would be really nice to have an explanation, ideally with links to resources/ articles/ code snippets/ libraries.
With web sockets it is possible to send HTTP headers.
HTTP Public Key Pinning (HPKP) is an Internet security mechanism delivered via an HTTP header which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise
HTTP Public Key Pinning is just a HTTP header on the server side.
On the client side, which really depends on the language/runtime, you might have to implement it yourself.
When talking about a browser as a client:
the initial attempt to establish the websocket connection still happens over a standard HTTP request and requires a standard HTTP request to be properly established. As a result, the browser should still respect any response headers sent back down by the websocket server when initially establishing a connection.
StackExchange - Information Security: Certificate Pinning for WebSockets
I am using EPP (Extensible Provisioning Protocol) to perform domain registration operations.
Everything works fine but when I use a certificate, the login request fails.
Let us say I have certificate in C:\Folder\epp.crt and using the following code:
var tcpTransport = new TcpTransport(url, port, new X509Certificate("C:\Folder\epp.crt"), true);
var service = new Service(tcpTransport);
service.Connect();
This code executes just fine and service is connected. That means connection to URL is established using certificate. Now, I try to login with:
service.Execute(logingCmd);
But this gives me "Server requires Client certificate validation, no client certificate provided".
Why? Should there be any flag for certificate in login command?
Per RFC5734, EPP uses TLS, not TCP. This RFC also mandates use of client certificates.
Your question lacks details about the content of epp.crt (where is the associated key?) or the language you use. The TLS negotiation, including validation of client certificate happens before the EPP login, but the exact moment may be hidden by the library you use to connect.
So to answer your "Should there be any flag for certificate in Login Command?", no there should not as the certificate handling is part of the transport setup, not the EPP commands. Your problem is probably more around your use of TcpTransport.
You can use a network sniffer to see exactly what happens. Registries are probably not offering TLS1.3 for now so you should still be able to see the TLS exchanges, including your client providing a certificate.
Also the registry you connect to should be able to help you.
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437