I have a situation and not sure if it has possible solution.
I have a Java Server with SSL Socket and certificates "A" & "B". I also have 2 types of clients - one with certificate "A" and another with certificate "B". However only one certificate is loaded on a server side and therefore either clients with cert. "A" can connect or only clients with cert. "B" can connect.
Is it possible to modify Java Server such that up on a connection from any client, it will determine which certificate is used ( A vs. B ) and use appropriate cert?
P.S: Please pardon my security ignorance.
Thank you.
Being able to use two server certificates on the same IP address and port is possible via the Server Name Indication (SNI) extension, which must be supported by the client and the server.
Java supports this on the client side since Java 7.
Unfortunately, this is not supported on the server side yet. This is planned for Java 8.
Meanwhile, if you do need SNI support on your server, you may be able to use another server to handle the SSL/TLS connection and forward the plain text connection to your application. Typically, this can be done with Apache Httpd (with a reverse proxy) for HTTP(S).
Alternatively, it looks like the HTTPS-SNI-Proxy project may be more flexible for other protocols (despite having HTTPS in its name). I haven't tried it, but according to its README, it looks for the SNI extension in the initial Client Hello and then forwards the entire SSL/TLS connection (without deciphering it) to another server, depending on what is configured. In your example, you would have to set up two SSLServerSockets on distinct ports (not the one you really want to listen to) and forward connections from this tool to either port depending on what the client requests with its SNI extension.
Related
So i have my site on hosting company, and this company support let encrypt certificate, so i generated it and now the site is running with https protocol.My server side(spring boot application web service oriented started on VPS) for this site is on another company. My questions are:
How can i use this generated certificate on my server side part,
is it possible, what should i do?
What i need to provide to the server, and all things that are needed the server to work?
When i was without the certificate everything worked perfect, but right now on the server side i get
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
and in the browser i get
net::ERR_SSL_PROTOCOL_ERROR,
when I`m trying the get resources from server.
From the hosting company i can get everything connected to the certificate
It seems that you are passing HTTPs traffic to web server which "talks" in plain HTTP.
Normally SSL termination is done on software like Apache HTTPD or Nginx.
Then you configure it to act as reverse proxy to your actual Spring boot application running in JVM.
You can also configure your JVM webserver (Jetty,Tomcat .. whatever you have) to use your Let's encrypt certificate, but I have doubt that certbot will be able to easily renew them.
Another legacy support problem here!
We have a server multiple clients network where each component has a self signed certificate and is added to the server/client's trust store. We are not using a Certificate Authority here.
Now our problem is that we need to upgrade all the certificates for better security. The new clients will come with newer certificates and even the server will have new certificates.
Our problem is how to handle the old clients. Upgrading keystores of our old clients is the last resort.
Things that won't work:
Adding both the new and old certificates in server truststore: Even the clients are authenticating the servers and the server certificate will not be present in the client truststore.
Using new port for the new clients: We considered using new ports for new clients and continuing the old ports for old clients but the problem is that there are multiple applications which are facing this problem so we will have to search for multiple new ports which are not being used by other products.
FWIW: The servers are in Java and the clients are in C++
EDIT after EJP's answer
I am probably asking a very dumb question here but just wanted to be sure. There is absolutely no way to edit the SSL Context of a socket once it is bound. Correct?
Also, can we choose the server certificate to be used during the handshake? I know of chooseClientAlias() and chooseServerAlias() methods but here we don't know which certificate to use till the client Hello message is sent.
Leaving aside using different ports:
(1) will work as far as the server is concerned with the client certificates.
Nothing will work in terms of getting old clients to recognize the new server certificate, other than upgrading the client truststores.
This is why you should have used a CA, even an internal one, and why you should absolutely not make the same mistake again. If the clients had trusted the CA instead of a self-signed server certificate directly, you would not now have this problem, and you won't have it in future, however many times you upgrade the certificates, until the CA certificate expires, which should take 20 years.
And while you're at it, make sure you build in a way to update client truststores.
There is absolutely no way to edit the SSL Context of a socket once it is bound. Correct?
There is no way to edit the SSLContext once it is initialized, which precedes creation of sockets, let alone binding them. Hmm, maybe you could reload the KeyManager and TrustManager and just not tell the SSLContext, but I'm not saying it would (or wouldn't) work.
Also, can we choose the server certificate to be used during the handshake?
Yes, that's what the KeyManager interface is for, specifically chooseServerAlias().
I know of chooseClientAlias() and chooseServerAlias() methods but here we don't know which certificate to use till the client Hello message is sent.
chooseServerAlias isn't called until the ClientHello has been received.
In HTTPS technology, an SSL certificate is required for a secure connection. This certificate must be acquired through self-generation, or through a certificate authority (CA).
In Java, an SSLSocket to SSLSocket connection promises the same security as an HTTPS connection (No man-in-the-middle, encryption, etc).
When connecting two SSLSockets instantiated in two separate, stand-alone Java programs (One client, one server), is it necessary to supply Java (The server) with a valid certificate?
What are the methods used to specify which certificate to use? The documentation doesn't seem to have anything to say about this.
I'm talking about pure Java here. I'm not talking about using Java to connect to a web service via HTTPS.
The purpose of these sockets is to send user names and passwords from one Java application (The client) to another (The server) for identity verification purposes, so it is imperative that they are as secure as possible.
When connecting two SSLSockets instantiated in two separate, stand-alone Java programs (One client, one server), is it necessary to supply Java (The server) with a valid certificate?
In normal usage the server (the end with the SSLServerSocket) needs a certificate that is trusted by the peer.
The client only needs a certificate if the server is configured to require it, which is not the default.
What are the methods used to specify which certificate to use? The documentation doesn't seem to have anything to say about this.
See the JSSE Reference Guide. You can do this via system properties. You can also write a foot or so of code, but it isn't necessary.
If you want to have a secure encryption you need to have either a pre-shared key only known to both parties or you have to do some kind of key exchange to compute the encryption key. Key Exchange requires proper identification, otherwise a man-in-the-middle attack would be possible and you would not have secure end-to-end encryption anymore.
For use of pre-shared key look out for TLS-PSK. When googling for it it looks like that there are some hits for Android implementations but mostly it is people asking if it is possible. It might be possible to do this with the alternative SSL implementation BouncyCastle.
If not using PSK you might try to use anonymous ciphers (ADH). I don't know if they are supported by Java but in any case you would still need to have some kind of identification to make sure you are talking to the expected server.
And then there are of course certificates. You might use self-signed certificates together with public key pinning if you don't want to use public certificates for your application.
In HTTPS technology, an SSL certificate is required for a secure
connection. This certificate must be acquired through self-generation,
or through a certificate authority (CA). In Java, an SSLSocket to
SSLSocket connection promises the same security as an HTTPS connection
(No man-in-the-middle, encryption, etc).
No : HTTPS = HTTP traffic going through an SSL socket.
When connecting two SSLSockets instantiated in two separate,
stand-alone Java programs (One client, one server), is it necessary to
supply Java (The server) with a valid certificate?
Yes - Certificate and private key. If you want two way SSL, client would also need its own set of key/cert
What are the methods used to specify which certificate to use? The
documentation doesn't seem to have anything to say about this.
There's a lot of ground to cover. I'm not sure how much you already know, the things that you need to read up on include keytool, KeyStore, SSLContext, SSLServerSocketFactory, KeyManager.
Or you could directly go to examples like this
I have a java application that runs on client machines that receives ajax requests from web applications. Some of these web applications that would like to use the service are served only under https.
I have the java app now accepting and handling SSL requests just fine, but I must first navigate to the server in a browser and accept the cert.
What is the best method of having a 'real cert' installed as part of this java app that listens on https://localhost:my_port?
On windows, it seems I can have an installer add a self signed cert to the machines accepted list. I had also thought about getting a verified cert for thisApp.myDomain.com and then changing host files to point that address to 127.0.0.1, but changing host files seems malicious and I worry about that being picked up by anti-virus.
The 'main' application is a web based system. Some users of this web based system would like to be able to print to special printers on designated computers. The java app is to be installed on those computers, the web application then sends ajax requests to the java app, which interacts with the printers. End users need to be able to install this java service with an easy, one-click type of installer. The web app is run from a browser on the machines doing the printing, hence localhost.
As stated earlier, the web apps need to connect to the web server (currently residing with amazon) via https. The connection to the localhost print server does not need to be https for any reason other than Chrome complains about insecure content, and chrome is currently the most widely used browser by our users.
Any thoughts or suggestions?
If by "real" cert, you mean one that signed by a trusted CA, then I think that the answer is that you probably can't. I don't think a trusted CA will issue one for you.
The answer I linked to above suggests that you set up your own CA by getting a CA cert. The other alternatives are a self-signed cert for 127.0.0.1, or tweaking your DNS resolution (e.g. via the client machines' "hosts" files) so that some name with a valid cert resolves to a loopback address on your client machines.
BTW - turning off certificate verification is not the way to go. It is better to add a self-signed certificate to the trusted cert list of (for instance) the user's browser.
If I was in your situation, I think I'd change whatever it is that requires HTTPS for requests on 127.0.0.1. Either don't require HTTPS for the requests, or change the IP address to the client's own IP address.
I try to install self signet certificate on client machine - but fails. Don't remember what was the issue. So I turn off verification for certificate in client code.
You can read about it here.
I've got a web service which may be bound either to ssl or plain http. The java clients configured to know the server host and port. When client connects, I construct the server end point like http://host:port/service. Clients don't have a knowledge whether the server is using ssl - server always binds to a single port so that it's either secure or not. Now, the question is how to make a client to discover this without introducing another parameter? Can I challenge plain http request and then fall back to ssl (or vice verse) on a certain exception? Or I must explicitly introduce new connection parameter for the clients?
On the server side, you could use a mechanism like Grizzly's port unification implementation. This can be used to serve HTTP and HTTPS on the same port. This relies on the fact that in both cases, the client talks first and either sends an HTTP request or an SSL/TLS Client Hello message. It's quite handy for this on the server side (although I'm not sure I'd recommend running two protocols on the same port in general).
From the client's point of view (which is what you're asking about), the consequences of that are:
The fact that the client talks first means that it will always have to try first. Expect an exception of some sort if you try to talk SSL/TLS to a plain HTTP service and vice versa.
If the server uses port unification, there is no way you're going to be able to find out reliably.
Port unification aside (this is a rare case after all), you could try to cache results of past attempts.
More fundamentally, from a security point of view, not knowing which protocol should be used introduces a vulnerability: your system will be open to downgrade attacks (in a similar way as blindly relying on automatic redirects would). If your user-agent supports HSTS, it would be worth looking into that (although it would require the user-agent to remember which sites are to be used with HTTPS).
Either way, if you're concerned about security, you must configure the client to know when to use https://.