I've set up a websocket connection using Java-WebSocket with a working two-way TLS connection. However, to make Client Authentication possible I'd like to be able to get the information attached to the Client Certificate. This will contain some information about the client connecting so it would be useful to have.
I've looked through all the data in debug mode for the connection and the data it contains, but cannot find any reference to the certificate. Most questions online seem to be about the standard javax websocket, but the one I'm using is made by TooTallNate (https://github.com/TooTallNate/Java-WebSocket)
I would like to be able to get a certificate from an established session. Is this possible?
Apparently in the new version the possibility of getting the SSLEngine from a session has been made possible. This should be present starting from version 1.4.1, which is currently a SNAPSHOT.
For anyone else stumbling across this question, this is a solution that works as of the 1.4.1-SNAPSHOT build used. This code should function in any of the server events. In my case I placed this in the onOpen event, which I'm guessing is where you'd want it to be as well. I haven't fully tested this with a non-SSL server but since there is a check in place it SHOULD be fine. Please test beforehand, however.
Certificate[] certificates = null;
if(webSocket.hasSSLSupport()) {
try {
certificates = webSocket.getSSLSession().getPeerCertificates();
} catch (SSLPeerUnverifiedException e) {
logger.error("Could not read SSL Certificates");
e.printStackTrace();
}
}
Related
So I have this situation: I try to download an image from somedomain.com using HTTPS. The domain is probably misconfigured, but unfortunately I can't change that. What exactly is happening:
When I browse to https://somedomain.com/animage.jpg I get a valid certificate issued for somedomain.com, which is perfect. But when I call the same site using it's IP address, say https://123.123.123.123 - I get a (also valid) certificate for *.hostingcompany.com - the certificate of the hosting company.
Now, I try to download the contents of the file using Java's HttpsUrlConnection, nothing special:
var urlConnection = new URL(imageUrl).openConnection();
((HttpURLConnection) urlConnection).getResponseCode();
(I want to first check the response code, but it's not important here.)
This code runs inside a Spring Boot App and is run on request. It works fine for the first request since booting the app. Each subsequent request fails with java.security.cert.CertificateException: No subject alternative DNS name matching somedomain.com found. It's because on each subsequent request the SSL Handshake is sent to the IP, not hostname, and get's the hosting company's certificate.
I was trying to find different settings for the SSL classes, but to no avail. I know there is a workaround where I could supply my own HostnameVerifier which could just return true, but that won't be secure, so I don't want to do that.
Did anyone encounter such problem? Maybe I'm searching in the wrong places? Maybe it's something with DNSes? I will appreciate any help.
Turns out it is a bug in Java 11.01. It is fixed since 11.02. After switching to 11.03. the behaviour I described above is gone. Each request gets a proper certificate.
Here are the details of the bug: https://bugs.openjdk.java.net/browse/JDK-8211806
Our application uses Apache HttpClient 4.5.3 and we are observing a very weird behavior with communication between our client and the server using SNI capability
The server is configured to return a Go Daddy signed certificate if the SSL request comes in the with the server name expected from our client(ie: the host name of the server) and it will return a self signed certificate for all other domain names
Behavior observed
The client receives the correct server certificate on all server except on our production machine
The client code is running in an application deployed on tomcat 8, we have noticed that initial requests to the endpoint go through successfully. After some time of running we receive an SSL exception on the client.
The error is because the server is not sending the correct certificate(it sends the default self signed certificate)
If we restart the tomcat server on which the client is deployed, the calls again start to go through successfully.
We have used javax.net.debug for debugging purposes in the past but we cannot use it in this case as we need to restart the tomcat server for its effect to take place and when we restart the tomcat server, the calls to the endpoint server start to succeed.
Also the javax.net.debug logs a lot of information which will flood our logs and hence we wanted it enabled only for a specific request.
We are hoping to log only the Client Hello(which contains the server_name passed to the endpoint)
I have read through
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#OwnX509ETM
But not sure of what we can use to print only the SSL server name indicator pushed down to the server.
I had the same concern as yours, then firstly I was thinking about dynamically adding environment variable, but it's always taking old value. Then I found out that javax.net.debug environment variable is read once only with static block in SSLSocketFactory.java. The full source code is available here.
static {
String s = java.security.AccessController.doPrivileged(
new GetPropertyAction("javax.net.debug", "")).toLowerCase(Locale.ENGLISH);
DEBUG = s.contains("all") || s.contains("ssl");
}
In my project using grpc and java,I am using OpenSSL to make a secure connection between Client and server.
I am able to bring the grpc server up successfully.
The documentation here mentions that the client code for a secure channel is this
ManagedChannel channel = ManagedChannelBuilder.forAddress("myservice.example.com", 443)
.build();
GreeterGrpc.GreeterStub stub = GreeterGrpc.newStub(channel);
I am using the code at client as follows but the below exception is being thrown.
mChannel = ManagedChannelBuilder.forAddress(GrpcConstants.LOCAL_GRPC_CLIENT_IP, GrpcConstants.LOCAL_GRPC_CLIENT_PORT).build();
mEmployerServicesBlockingStub = EmployerServicesGrpc.newBlockingStub(mChannel);
mInviteContactsBlockingStub = InviteContactsGrpc.newBlockingStub(mChannel);
Exception:
Network channel closed
at io.grpc.Status.asRuntimeException(Status.java:431)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:157)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:106)
I tried with the following code also:
mChannel = NettyChannelBuilder.forAddress(GrpcConstants.LOCAL_GRPC_CLIENT_IP, GrpcConstants.LOCAL_GRPC_CLIENT_PORT).sslContext(GrpcSslContexts.forClient().trustManager(file).build()).build();
mEmployerServicesBlockingStub = EmployerServicesGrpc.newBlockingStub(mChannel);
mInviteContactsBlockingStub = InviteContactsGrpc.newBlockingStub(mChannel);
This is also giving the same exception as above. I just gave a null file reference here.
Please let me know which approach should be used for a GoDaddy certificate.
If it is the first approach, what am I missing.
If it is the second approach, which file am I supposed to use for "roots.pem".
Updated.
It looks like the exception is cut off a bit at the top. There may also be a causal exception ("Caused by:") that could be helpful. In either case, this may be similar to another issue, where gRPC "misses" the original error and is now just detecting later failures.
Both approaches to Channel creation should work. If you are using a reverse proxy, I would assume the problem is either the server not supporting AES GCM or ALPN (with HTTP/2). You can use https://www.ssllabs.com/ssltest/ to check for support. For example, Google supports both. If you are contacting a gRPC server directly, I would expect an issue initializing tcnative.
It is probably worth-while to create a GitHub issue to help us in tracking down the true cause.
I have a certificate which i need to pass along with the SOAP Request in JMeter.
I have edited the system.properites file to add
javax.net.ssl.keyStore= path to keystore file
javax.net.ssl.keyStorePassword=password
I am still getting the error You need valid client certificate from DHW to access page.
Am I missing somethig here?
The same request is working well from SOAP_UI.
There is a lot that can be going wrong here.
Here is my guess though...
The server is most likely setup for mutual authentication. You can test this by running your java client with the following system property: -Djavax.net.debug=ssl
You should see the ssl handshake and see if the server is requesting a client certificate or not. The messaging will be VERY verbose and you will have to diligently look though the log output to see what is actually occurring.
Hopefully, in the output you will see a list of Certificate Authorities (CAs) that the server trusts. Your client's certificate MUST be signed by one of these CAs. If not, the client won't even attempt to send its client certificate.
If you have access to the server, you can create your own CA and then sign the clients certificate with that new CA and that will work. I actually just did that yesterday. :D
The issue is resolved. I was giving only single backspace instead of two backspaces as per java conventions. It works fine with this minor modification.
I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks
It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.
As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).
You might also be interest in this similar question.
Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.