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.

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.

Servlet and TLS

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.

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

Mirth: calling an SSL SOAP web service with a client certificate

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