I have developed a java application that uses a Signature Pad to capture biometric signatures. The Pad is plugged to the Client computers so i need to run the java controller on each local machines. To do that we run a JAR that contains a Jetty server. We use websockets protocol to start the signature process from the browser and to send data to the Jetty server.
The problem: We need to create a certificate for the websocket secure connection and this certificate must be emitted for 127.0.0.1 since the Jetty server is running on the Client local machines.
If I create a self-signed certificate the solution works fine but some browsers, for example Firefox, does not allow self-signed certs as trusted certs and I doubt that a CA issues a certificate for 127.0.0.1.
So, what would be the best solution? Keep using the self signed cert? Is there any other way?
If you have admin privileges on the POS terminals, how about adding a line to the HOSTS file like:
127.0.0.1 localhost.mycompany.com
Now you can use a real certificate for localhost.mycompany.com in the server application.
(From How can I establish a secure connection to a websocket on localhost?)
Related
I was curious if anyone knew how to implement a Dynamic MTLS solution in Jetty? We have a use case where we need to do device authentication. We want each device to have a different client certificate for security reasons. Is there a way to dynamically pull and validate the server certificate with the one the client sent in? I was combing through the SslContextFactory and ServerConnector java classes, but could not quite figure out which method to override if I extended them. Any help would be greatly appreciated.
The canonical way would be for each device to have a certificate D signed with a server certificate SS.
Note that the server's signing certificate SS may be different (and typically is) from the server's domain certificate.
The server (or a similar authority that you control) emits signed certificates for new devices (a certificate Dn signed with SS).
Basically the server acts as a standard Certificate Authority.
Certificate SS need not to be signed by another authority, as long as it's trusted by the server (i.e. it's in the server TrustStore).
There is no need to extend any Jetty class, just use the standard PKI processes and tools, and then the only thing you need to do is to configure Jetty accordingly.
I would recommend deploying your own PKI and have server and devices certificated issued by your own authority. Simone's answer on using server certificate to sign clients will stop working if you change server certificate and you do not want server certificate with long validity.
I'm hosting a web game on github pages. It's a react app that connects to a websocket server (via wss) running off of a linux box in my living room. I've generated a self-signed certificate for the server, and github-pages already has a Let's Encrypt certificate by default. Presumably because the cert is self signed, the client refuses to connect to the "insecure" server and I am not prompted to install the certificate or anything, because the client does have it's own separate certificate. Would just buying a real certificate solve all my problems? Should I just host the website from the same server and figure out all the stuff associated with that (I realize this is probably the best answer)? What's the public opinion on having separate ssl certificates for client and server?
you can add your self signed certificate to your local truststore, but it's a little work and everyone connecting to your site would have to do it.
buying a certificate would solve this problem, because it is then signed by a trusted certificate authority which allows everyone to verify your servers identity.
on the other hand, if you move your ui to the self signed server too, the web browser will prompt (respectively warn) the user about the untrusted certificate and the user is about to say wether he wants to advance to the site or not. this would "solve" the problem too.
last, but not least. it's quite common to have ui and backend separated and therefore having separated certificates too, but not in such little applications. in a big environment definitely worth it, because it's a separation of concerns.
I have a java process running on a remote server that exposes a SSL configured JMX port using the com.sun.management.jmxremote JVM arguments. The process uses a keystore that contains a self-signed certificate.
I am running Java Mission Control (JMC) on my local machine to connect to this remote JMX port. I have setup JMC with a truststore that has imported the self-signed certificate from the remote keystore. This is all great and I can connect with secured SSL as expected.
I checked the details of the self-signed certificate recently and was surprised to see that it had expired a month ago as I would have expected to have not been able to connect to the remote process using JMC, but I have been able to connect just fine with no expiration warnings.
I have confirmed that it is indeed using this certificate as when I run JMC without the truststore and try to connect I get a Certificate Path Building Exception. I have also looked at the SSL debug and can see the certificate is used.
Could anyone explain to me why I am still able to establish this connection using an expired certificate? If this process exposed a RESTful service that I connected to in a browser would I expect to not be able to connect or would I just get a warning (or nothing at all like in JMC).
Thanks for your time.
After further investigation I have found that the Trust Manager used by Java Mission Control will accept expired certificates without warning. However, it will prefer a valid certificate over an expired one should both be available. I am not aware whether or not this behavior can be changed.
Suppose I am a java web server application . I want a java client to be able to connect me from a java application by REST on https over the internet.
So I got my CA certificate and add it to my truststore and created my keystore.
My question is : Does the client application have to get anything from me (a file or any other information) in order to be able to establish this connection (regarding this ssl issue I mean) ?
Thank you
If your certificate is signed by CA, client doesn't need anything else. If it is self-signed, client will need same certificate to compare.
I am working in an environment with the following configuration.
A Java server (outside my control) is hosting web services guarded by two-way SSL.
The server truststore contains a specific certificate to trust, instead of an entire CA to trust.
The specific certificate in question is a client certificate that I have access to.
In most cases, the application in question (e.g. SoapUI, Firefox, Chrome) won't send a client certificate to the server, despite one being installed in the local keystore or otherwise installed.
The only success I have had was with using Safari on my mac, as it allowed me to choose which client certificate I wanted to send.
Both the Client and and Server certificates are signed by the same CA, if that matters at all.
Is there any way to make this work without server-side changes?