We Keep Coding

Using ServiceTalk from Apple (Netty) as a RESTful API with Jersey and Let's Encrypt HTTPS

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.

SSL client (Java) is not sending a certificate back to the server in two-way SSL handshake

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

IS it possible to have One way and mutual ssl for same web App same time depending on URLs

I have a scenario where I have few rest web services, of which few need to enforce mutual ssl and few should just have one way ssl, here its same web application.
Is that possible in tomcat/Spring based application?

Sorry for replying late, yes I did this, not sure if the best way but kind of a hack.
Step 1: Have one way SSL set with clientAuth=want in your tomcat.
This will fix your scenario where you want to have one way ssl for all the webservices accept that one which needs extra/mutual authentication.
Step 2: Now for the web service which needs mutual ssl.
Write a servlet filter and for that particular web service url check the incoming http request for certificates. loop through the certs found in the request and match it with the certs from your trust store. if you found the match let the request flow proceed, if not return an exception as SSL cert not found.
X509Certificate[] certificates = (X509Certificate[]) request
.getAttribute("javax.servlet.request.X509Certificate");
The above code will give you array of cert in your request.
Note: Make sure your SSL configuration is correct or else the certificates variable stays null.

If you can use different hosts (assuming the client and server support SNI) or ports, then this should be no problem.
Unfortunately, you cannot vary the SSL configuration based on the URL's path since it is only available after the SSL connection has been established. Your only option in that case would be to make the client certificate optional and ignore any certificates sent for the URLs that do not require it.
In either case, you will almost certainly be better off letting something like Nginx or Apache httpd handle the SSL part and pass any data about the client's certificate (or lack thereof) to your Spring / Tomcat app in an HTTP header.

You can use TLS ("one-way") for your whole site and then only demand a client certificate when authentication is required. Set your TLS <Connector>'s clientAuth attribute to want and set your auth-method in web.xml to be CLIENT-CERT. That ought to do it.

ssl client authentication without ssl re-negotiation

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

How to enable optional client certificate requests in GlassFish?

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