I posted this issue and i could solve it deleting from the WebLogic startups parameter the next:
-Djsse.enableSNIExtension=false
Can someone explain this?
The parameter -Djsse.enableSNIExtension=false disables SNI.
Let's say you go to endpoint endpointaaa.com/aaa. Behind this endpoint endpointaaa.com there could be multiple application servers, all with their own certificate. So /aaa could point to server A and /bbb sould point to server B. SNI let's you send the endpoint you are trying to reach in it's initial contact (SSL handshake I think?). This will let the receiving end know, to which application server you are trying to connect, so it can response with the right certificate.
If SNI isn't enabled, it's possible that a different application server responds with a different certificate.
Related
I'm running an ActiveMQ server with SSL authorization (via trust store).
The clients are written with Spring Boot and Camel. Each client has it's individual certificate.
When the client's Java version is updated to version 1.8_271 the SSL connection suddenly fails. This can be found in the ActiveMQ logs:
javax.net.ssl.SSLException: Received fatal alert: unexpected_message
After downgrading to 1.8.0_261 everything is back to normal.
And here is where it gets really weird: my ActiveMQ truststore currently contains 232 certificates. When I delete 2 of them (does not matter which one) the connection with the 1.8_271 client works again.
This really does not make any sense to me. How can the number of items in the server's truststore have anything to to with the client's Java version?
Some updates:
I'm testing with the ActiveMQ Docker image
Changing the key store type from native JKS to PKCS #12 does not make a difference
Using Java 1.8_271 on the server side behaves the same but shows a different error message:
java.net.SocketException: Connection or outbound has closed
From the release notes
Improve Certificate Chain Handling
A new system property, jdk.tls.maxHandshakeMessageSize, has been added to set the maximum allowed size for the handshake message in TLS/DTLS handshaking. The default value of the system property is 32768 (32 kilobytes).
If your server requests client authentication, JSSE (edit) below 1.3 sends a CertificateRequest message specifying acceptable CA names derived from the certificates in your truststore, thus the number of certificates in your truststore affects the size of this message and may make it exceed the limit in which case the client rejects it (although I'm not sure I like using unexpected_message for this case).
I have client and server configured to use TLS and self-signed certificate.
Client SSL Engine is configured to use dummy trust manager, which doesn't ever throw CertificateException and empty KeyManager array.
Server SSL Engine uses key store which is initialized with manually generated key store file.
When I run it with JDK 8 I get the following handshake result:
Server fails to validate certificate
In client's thread I can see that io.netty.handler.ssl.SslHandler#setHandshakeFailure is called
and io.netty.handler.ssl.SslHandler#setHandshakeSuccess is never
called.
Which is expected behavior.
When I run it with JDK 11 I get the following:
server fails with the same error (empty certificate chain) but in client thread I see the following:
io.netty.handler.ssl.SslHandler#setHandshakeSuccess is called first
io.netty.handler.ssl.SslHandler#setHandshakeFailure is called after
I'm new to TLS 1.3 and might missed something in configuration. At the same time documentation says there's nothing to update for java TLS API clients to switch to TLS 1.3.
This behavior is confusing and it breaks further logic based on handshakePromise.
Full code to reproduce the issue is available by gist link:
https://gist.github.com/kiturutin/ccb710f67ccfb0a7a7de1fb3b3099b60
It's a groovy script and it first starts server then client.
To be clear, your server requests client auth and server validation of the client cert fails because the client is configured with no keymanager and thus sends no cert? (Whereas server sent its own 'manual' cert okay, and client accepted it because of the dummy trustmanager.)
If so this looks like a similar problem jetty has(?) -- see the fifth post in https://github.com/eclipse/jetty.project/issues/2711 -- and it appears to me this is because TLS 1.3 client considers the handshake complete on sending Finished (because 1.3 moves server Finished to first flight) and that's before receiving the server alert for client auth failure. (Whereas in 1.2 and earlier, server Finished and possibly Ticket basically is the second flight, causing an extra RTT for client-first app protocols -- like HTTP.)
It is also before receiving server NewSessionTicket (as modified for 1.3 'resumption') if used; see OpenJDK 11 problem - Client finished handshake before last UNWRAP .
I guess for 1.3 you have to accept 'failure' after 'success', unless the Java folks can think of some really clever fix for this.
On the server side, it is possible to specify whether you want to send a client-certificate request to the connecting clients:
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html#setWantClientAuth(boolean)
For completeness, you can also specify whether you want to negotiation to continue if the client does not provide a certificate:
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html#setNeedClientAuth(boolean)
My specific question is: given a client application written in java, is it possible to somehow know whether a server requested a client certificate during the negotiation (i.e. the server your application is connecting to was configured with setWantClientAuth(true))?
You can install a KeyManager that does nothing but delegate to the default and set a flag if it was called.
Or if you're directly using SSLSocket or SSLEngine after the handshake you can check .getSession().getLocalCertificates()/getLocalPrincipal(). Thanks to #dave_thompson_085 for that.
We are trying to access a restful web service resource hosted on IIS server with https protocol.
When we disable TWO WAY SSL Auth (server side validation of client certificate disabled) everything works fine.
When the IIS imposes TWO WAY SSL (server side validation of client certificate enabled) we are getting the below exception:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
We are using java 1.8 update 102, IIS server 7.5 and TLS 1.2 for ssl
For detailed issue please open the below link:
For details SSL Debug log, certificates, client program
It will be great help if someone help us.
Thanks!
See this warning in the SSL log:
no suitable certificate found - continuing without client authentication
Your server is sending a list of accepted CAs to request a client certificate, but your client does not find a suitable one. It seems your keystore has the correct certificate. Ensure that your certificate is correct, for example installing it in the browser and navigating to a protected resource
May be it is a configuration issue of your Java client. Please read HttpClientBuilder documentation carefully
System properties will be taken into account when configuring the default implementations when useSystemProperties() method is called prior to calling build().
You did not call useSystemProperties().
See also this bug report that might affect you https://issues.apache.org/jira/plugins/servlet/mobile#issue/HTTPCLIENT-1477
I have to call a SOAP web service having client authentication over HTTPS.
I have imported the client certificate (got from company hosting the server) into by keyStore file. I also imported server certificate (downloaded from server) into my trustStore. I have set 'javax.net.ssl.keyStore' and 'javax.net.ssl.keyStorePassword' to the appropriate values.
When I call the web-service from a simple java client (including just some additional jars), the call works and I get a result from the server.
When I call the web-service from within glassfish-4 (same java, same keyStore, same trustStore, same 'javax.net.ssl.keyStore' value etc), I get an exception 'com.sun.xml.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: Received fatal alert: unknown_ca'.
I use the same java, same keystore, same trustStore in both cases. The first version without glassfish works, so the certificates seems to be ok. The second version with glassfish does not.
Does glassfish-4 do anything specific?
Can it be a problem of other (third party) libraries?
Are there any additional HTTP/SSL settings that I can try out?
What else can it be?
Anybody an idea?
Thanks for help.
I have found the problem.
Glassfish needs the additional VM property 'com.sun.enterprise.security.httpsOutboundKeyAlias'.
This has to be set to the alias of the client certificate.
For standard this is set in domain.xml in the java-config area.
For standard this is set as -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as.
Change the value s1as to the alias of the certificate.