0

In my project I have to integrate with another system which uses quite specific SSL (and also specific cipher suite). Here's what I mean.

Whenever I try to access the server with Java (send a request), I get the wrong certificate from Server Hello. Subsequently, I get a handshake failure, even though I have installed root and lk.egrz.ru certificates in java's cacerts

enter image description here

However, if I try to access the same server but with a browser with installed server certificates on Windows machine (root and lk.egrz.ru), I get the right one and a handshake succeeds:

enter image description here

My question is whether it's possible to have such SSL which can deliberately send a wrong certificate if client is accessing the resource not with a browser, but with an agent.

I have no idea why in some case I'm presented with a wrong certificate and in another case with the right one.

Thanks in advance

Rus9Mus9
  • 15
  • 4
  • This is most likely due to the fact that your Java installation sends a different "Client Hello" than the browser. Since those are absent from your screenshots, I can only speculate. –  Dec 11 '19 at 07:08
  • And furthermore, the usage of TLS 1.0 is highly discouraged and should be deprecated in favor of TLS 1.2 and 1.3 –  Dec 11 '19 at 07:13
  • To what should I pay attention there most? – Rus9Mus9 Dec 11 '19 at 07:21

1 Answers1

2

Nothing really is known about your client and the screenshots don't provide enough information about the ClientHello send by the client.

But the typical cause of this problem is that your client does not use Server Name Indication. SNI includes the expected target domain in the ClientHello and is needed if multiple domains with different certificates are hosted on the same IP address. If the client does not use SNI the handshake will either fail on the server side or the server will return one of the several certificates it has for this IP address which might not be the one the client expects.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Hello, Steffen Thank you for your answer. What type of information do you also need to confirm that the root of the problem is not using SNI? – Rus9Mus9 Dec 11 '19 at 07:32
  • 1
    @Rus9Mus9: The SNI can be seen as `server_name` extension in the ClientHello. Thus it would be relevant both if this extension exists and what value it has. – Steffen Ullrich Dec 11 '19 at 07:57
  • This is probably the correct answer. You can confirm this by using `openssl s_client` with the `-servername` option to specify different SNI server names, and examine the certificate that the server returns for various server names. For more info, see https://www.openssl.org/docs/man1.0.2/man1/s_client.html and https://stackoverflow.com/questions/43785703/using-servername-param-with-openssl-s-client. – mti2935 Dec 11 '19 at 10:34
  • Thank you very much, my client hello from Java doesn't have server_name while the request from the browser does. Is there a way to change it? My Java's SSL client doesn't support SNI – Rus9Mus9 Dec 11 '19 at 15:06
  • @Rus9Mus9: *"Is there a way to change it? My Java's SSL client doesn't support SNI"* - this need to be changed in the code of the Java client. In general Java can do SNI since years, so it might not be setup properly in your client or your client is too old. There are [lots of posts on stackoverflow.com](https://www.google.com/search?q=java+sni++site%3Astackoverflow.com) about this topic. – Steffen Ullrich Dec 11 '19 at 15:15
  • No, it really does not. We use a third party library for making SSL connection.The reason for that is because the server uses specific Cipher suite called GOST (Russian cryptographic algorithm) – Rus9Mus9 Dec 11 '19 at 15:38
  • @Rus9Mus9: The cipher is actually not relevant to the use of SNI. When end-to-end encryption is required than there is no other way then either to fix the client to support SNI or to change the requirement for SNI on the server. – Steffen Ullrich Dec 11 '19 at 15:49
  • Ok, I see, thank you very much for your answer! – Rus9Mus9 Dec 11 '19 at 15:50