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
Related
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
I'm developing a simple web services using Java EE Servlets.
My clients are a simple java apps (no browsers), so I need to secure my communication using TLS (or SSL v3). About Application server, I'm using Glassfish v3.
For example, I need to transfer some data from client to server within a HTTP Post Request into a secure connection.
There are some external libraries, server configurations or tutorial that can I use?
On the server side you must somehow expose your servlets via HTTPS. If you are using tomcat, check out SSL Configuration HOW-TO. If you have an Apache web server in front, see: Apache SSL/TLS Encryption.
On the client side ssl and https support is built into JDK, just call any https://... address using URLConnection. However remember that the certificate your server uses must be trusted - either confirmed by some authority or added manually on the client. Self-signed certificates by default won't be accepted.
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
The scenario is around calling an external SSL SOAP web service from within Mirth. The web service is requires an SSL/TLS connection along with a client certificate.
The intention is to use the built-in SOAP Sender Destination to call the remote secure web service, and somehow include that client certificate.
I understand that you first need to install that client certificate into the Java runtime. This may be within the Java runtime's certificate store or the Jetty certstore.
The platform:
Windows 2003 SP2
Mirth 1.8
Java jre1.5.0_09
Question: what configuration steps (Mirth, JRE certificate stores, etc.) would you suggest to successfully have a Mirth SOAP Sender include a client certificate (*.cer) when calling a web service secured by SSL?
The Java runtime, or more specifically, the Sun JSSE provider, will present a client certificate if some system properties are set. You can read details in the JSSE Reference Guide, but the important properties are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.
There are a few drawbacks to this approach. First, setting the key store password as a system property makes it accessible to any code running in that process—although this can be controlled if a SecurityManager is installed. Second, these settings will be used for any SSL sockets created through the "default" SSLContext. If you need different credentials for different endpoints, you'll need a Mirth-specific solution.
No starting point was specified in the question, but if starting from scratch, the easiest approach is to create a new Java Key Store ("JKS" format) and generate a new key pair and a CSR. After sending the CSR to the CA and getting a certificate back, import it into the same key store. That key store is ready to use.
If a certificate is already available, it is likely to be in a stored with its corresponding private key in PKCS #12 format (.p12 or .pfx file). These can be used directly by a Java application, but the javax.net.ssl.keyStoreType property will need to be set to "PKCS12"
Mirth 1.8 cannot send a client cert when calling a SOAP web service.
I'm late a bit here for this but actually there is a possibility that it could. By sending a few config parameters to the JVM you could get the underlying SOAP engine to switch to HTTPs and provide the proper certificate.
refer to this question for details on which parameters to set for configuring the VM
Java HTTPS client certificate authentication
you will notice there are quite a few things to take care of. Normally HTTPs and client authentication should "just work" once you configured your certificates appropriately. BUT there are some servers out there that are not so friendly to B2B style clients so you have to watch out.
Using JDK 6_21 and a few tweaks with the certificate I was able to get one of them servers to behave but it was long and painful on our side for something that takes about 15 minutes to configure properly on the server.
here is another question that address this very issue (client side authentication towards unfriendly servers).
Client SSL authentication causing 403.7 error from IIS