On client side I have Apache HTTP client on jdk5u22. On server side I have tomcat on jdk6u27.
With this setup if I try SSL Client authentication (2 way SSL) then it cause "javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed" on the server and handshake fails. It succeeds if I set system properties sun.security.ssl.allowUnsafeRenegotiation=true and sun.security.ssl.allowLegacyHelloMessages=true on server.
As per the link http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html this is coz JRE6u27 has the RFC 5746 implementation and JRE5u26 below doesnt have this and so both are incompatible. Unfortunately 5u22 is the latest freely available java 5 version. So I want to know if it is possible to have SSL client authentication without ssl re-negotiation.
Regards,
Litty Preeth
As per the redhat site https://access.redhat.com/kb/docs/DOC-20491#Renegotiations_disabled_in_Apache_Tomcat :
Tomcat may ask the client to renegotiate in certain configurations using client certificate authentication, for example, configurations where:
A client certificate is not required on the initial connection, such as when:
1. The clientAuth attribute of the HTTPS connector using JSSE is set to
false. Or The SSLVerifyClient attribute of the HTTPS connector using
OpenSSL is set to none.
AND
2. A web application specifies the CLIENT-CERT authentication method in
the login-config section of the application's web.xml file.
So to avoid re-negotiation in tomcat just make the whole site secure and not just a part of it by setting clientAuth="true" for ssl .
Hope this helps someone.
Regards,
Litty
Related
So basically, I have made a RESTful API using ServiceTalk from Apple (Netty implementation) and Jersey and it works. Only through http though. I have seen that when I was making my React web page make a POST request through http, it would complain about CORS (which I'm still trying to fix) and that the browser (At least Brave) would not allow the request to be made because it was http and my web page was running on https using let's encrypt cert. How do I fix this issue? Do I need to add SSL with Netty? If so, how can I do that with a certificate that's going to be changing every once in a while?
I also have NGINX setup with Let's Encrypt and enabled auto-renew certificate setting from the setup wizard for NGINX + Let's Encrypt. If I can somehow make NGINX run the HTTPS request as a proxy to the netty server on http, then I think it would also be a better solution. I know this is a common practice with NodeJS Express + NGINX.
You are right, if you already have NGINX that serves your static content (html/css/js) it will be better to configure it as a proxy for a ServiceTalk backend service. That will let you keep SSL/TLS configuration in one place (NGINX config file only) and you will be able to use its auto-renew certificate feature. For an example of how you can configure NGINX as an SSL/TLS proxy for a backend service, see here: https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/
However, in this case, your connection between NGINX and ServiceTalk will not be encrypted. In some environments, it might be inappropriate according to security policies and requirements. If this is your case, you also need to configure SSL/TLS for ServiceTalk using HttpServerBuilder.secure() method that returns HttpServerSecurityConfigurator. Here is an example of a secure ServiceTalk server.
To avoid CORS, keep using NGINX as a proxy even when ServiceTalk also configured with SSL/TLS connections. If there is a requirement to avoid additional proxy on the way between a browser and backend service, target ServiceTalk directly. But NGINX gives additional features, like load balancing between multiple backend instances.
To get the best SSL performance in ServiceTalk/Netty we recommend to use OpenSSL provided instead of a built-in JDK provider. For more information, see Performance / netty-tcnative OpenSSL engine documentation section.
Note: ServiceTalk does not auto-renew SSL/TLS certificates. You will need to restart the server when certificate expires.
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 a couple of java servlets which need to be secured with Mutual authentication with X509 certificates. I used the information from here to
implement mutual authentication and it works fine on my machine.
Now our integration environment has BigIP for load balancing traffic to weblogic. The SSL is terminated at BigIP and it forwards the https request to weblogic using an internal certificate instead of the client's certificate it got with the original https request. So mutual auth is not working.
The BigIP team says they can put the client's certificate in the HTTP header (SSL_CLIENT_CERT), and I am not sure how to configure weblogic to read client's cert from http header.
Do I need to write a custom Identity assertion provider and configure it in weblogic?? Is this the best approach or do I have any other option?
Any help on this is greatly appreciated!!
It is necessary to configure the identity asserter if you are using two way ssl to verify the client identity
and to use it to restrict access to application.If you are using two way ssl with signed CA(Verisign etc.) it
will be only used for trust -not for authentication or any type of application access restriction.
Check below link for detail clarification on above
http://www.oracle.com/technetwork/articles/damo-howto-091164.html.
You can follow your steps for configuring the X509 Certificate Authentication for weblogic server.
Along with above you need to follow below steps
1) Make sure that BIG IP handles client certitifcate and client key which can be configured in the HTTPS monitor in BiG IP.
2) Configure the BIG-IP to insert a header named WL-Proxy-SSL: with a value of true into each request.
3) Enable weblogic proxy plugin tab in
AdminConsole —> Servers —-> [Your_Server_Name] —> Configuration [Tab]
—> General [Sub-Tab]
Click on “Advanced” Link
Check the CheckBox in this Page “WebLogic Plug-In Enabled”
Above changes will help in undersatnding the weblogic that request coming from BIG IP was initially the SSL enabled.
Check below link for configuring WL-Proxy-SSL with BIGIP
https://support.f5.com/kb/en-us/solutions/public/4000/400/sol4443.html?sr=10058313
The Blog site (Client-Auth REQUESTED in GlassFish) reads:
In domain.xml, please add the following property to http-listener element
<property name="com.sun.grizzly.ssl.auth" value="want"/>
However, when adding this to my GlassFish v3 domain.xml, the existing browser client certificate is not requested. The GlassFish server is properly set up, i.e., requires client certificates with the option "client-auth-enabled" set to true.
The GlassFish bugtracker (1) mentions a different version:
* client-auth: want/need/<blank>
However, this property doesn't get accepted either.
Others have the same problem (2).
How can I enable an optional client certificate request in GlassFish? Are there alternatives?
(1) http://java.net/jira/browse/GLASSFISH-6935
(2) https://stackoverflow.com/questions/3634129/configure-glassfish-v3-client-auth-requested-to-want
Probably because it doesn't exist.
*When you deal with client certificates in HTTPS, keep in mind your HTTPS listener configurations. The SSLv3/TLS protocol allows three modes for an HTTPS socket.
* The traditional mode requires a single server certificate. An HTTPS client (typically a web browser) validates the server identity by matching the certificate to a list, or truststore, of Certificate Authorities. You probably use this mode every day during typical log-in activity.
* Another mode requires both client and server certificates. The client certificate is validated by the server side, and the server certificate is validated by the client side.
* The third mode requires a server certificate, but the client certificate is optional.
*In the real world, you want to use the same HTTPS URL whether a user is authenticated by password or certificate. This approach requires a server that supports the third, optional client certificate mode. At this writing, the GlassFish application server does not support this mode. Fortunately, the Apache Tomcat web server, supported by OpenSSO, is available as an alternative. For Reference
I would like to run a servlet in Jetty on an HTTPS site that requires a client certificate for only part of the site (specific URLs). For example:
https://example.com/someservlet/public - no client cert required
https://example.com/someservlet/protected - client cert required
In Apache I can accomplish this by specifying SSLVerifyClient require inside a <Directory> or <Location> which forces Apache to renegotiate the SSL connection after the request is made.
I do not want to run Jetty embedded in anything else, just standalone. Is this possible? Can a Servlet cause this directly somehow? Can it be done via configuration?
As far as I know you can only specify the SSL options on a per-port basis.
Even if you could the configuration you are trying to achieve is problematic, as it needs the SSLRenegotiation which has been changed about a year ago because of a security vulnerability. The new method for performing an SSLRenogitiation is therefore only supported by newer clients and sometimes even if it is supported it does not work because of bugs.
My recommendation for an easy workaround: Configure Jetty to listen on two SSL ports:
For example on 443 without HTTPS Client auth and on 8443 with HTTPS client auth required. Then make your protected servlet only available on 8443. This is not a nice solution but 100% robust, works with Jetty and with all clients.