We're talking about Let's Encrypt here, right? Because the official client already provides you with fullchain.pem.

If not, then you're a) not giving us enough information to work with and b) are you at the right place to ask these questions? This is the Let's Encrypt Community Questions about random TLS/certificate questions which do not have anything to do with Let's Encrypt are probably best asked somewhere else as far as I'm concerned. You'd probably have more luck, because I'm not really understanding your problem to be honest..

Hi thanks much @melo for this solution. LetsEncrypt works great now in my environment for Chrome browsers. The problem is that it doesn't work for Firefox. I'm looking at @eswn's solution for the FF problem in Apache here: https://community.letsencrypt.org/t/cert-not-work-in-firefox/5272/9. But importing the chain file he refers to to my java keystore does not resolve the firefox problem. How do I get LetsEncrypt working correctly for tomcat and Firefox?

I'm not really familiar with tomcat, but generally when you run into issues like this where things work in one browser (or on one device) but not in another, it's often because the correct intermediate certificate is missing. Browsers cache those intermediate certificates, so if (for example) you visited some other site using a recent Let's Encrypt certificate in Chrome but not in Firefox, that would make Chrome work but Firefox fail. Basically, don't think about it as a browser issue, but rather something that's missing from your server configuration. I would recommend using SSL Labs to verify you're serving the correct intermediate certificate.

If you find out you're serving the wrong intermediate certificate and need to get the right one, you can find both the old one and the current one (X3) here. You'll want to pass that to openssl as -CAfile chain.pem when creating your PKCS12 file.

Hi @vlott I am glad my post is helping. However I am afraid you might have got it a little wrong. @pfg summarized it perfectly.

There is no issue with the browser itself. We must ensure you are serving the entire chain required to accept your certificate as trusted. SSL Labs is a good tool to check whether you serve the entire certificate chain or if something is missing.In case you serve on a port other than 443, you can use SSL Checker and provide your domain and custom port.Run the test on your site. It will list the server certificate and any additional certificates, if provided. You must also provide the intermediate certificate for the certification path to be complete

To achieve this, as stated in my post, it is important that you use the fullchain.pem file that was generated together with your certificate like so:openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out fullchain_and_key.p12 -name tomcat

I later use keytool to convert this to JKS and setup Tomcat's connector accordingly, but I was told that Tomcat supports PKCS12 keystores, so the keytool step might be unnecessary.

Hi @sintroo I believe that it is perfectly fine to NOT provide the DST Root X3 certificate. This is a certificate from IdenTrust, a widely accepted and trusted certificate authority. This means that their certificate is included in several certificate authority trust stores, e.g. the ones of operating systems (used by browsers) or the Java CA trust store.

For a valid certification path it is fine to NOT provide the root CA certificate. Your generated cert says it is signed by LE, so you provide the LE cert for it to be available for validation. The LE cert is signed by DST, so for validation DST will be looked up in the available root CA trust store, were it will be found. This will give you a valid path of your-cert -> LE -> DST and you only need to provide your cert and every other cert required to build a path to a root cert, which in our case this is just the one LE cert.

@sintroo I guess it depends on the used java version. Java comes with keytool. You can use it to list the entries of a keystore. To list the trusted CA certs you could try running this on your server:keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts

But I am not sure what your problem is exactly.The DST Root X3 cert missing from the java trusted CA store would only be relevant when accessing your server with a java client and trying to validate the provided certificate.There is nothing you need to to on your server for the DST Root X3 cert.

Thanks @melo, I saw your updated command further down in the other thread. This worked great for me and I am up and running in SpringBoot. If anyone is interested in what I did to get working with the embedded tomcat in SpringBoot, just reply and I'll post.

Thanks @melo, I struggled for so many hours and thanks to your guide I now have a working tomcat server on a raspberry pi with free ssl certificates from let's encrypt and a free subdomain from selfhost.eu

I have a new preferred solution for HTTPS to Tomcat with Let's Encrypt certificate. I do not configure Tomcat for HTTPS in the first place!In case your setup consists of both a web server and Tomcat, consider setting up a reverse proxy on your web server and let it handle HTTPS for Tomcat. This way you can benefit from Let's Encrypts automatic certifcate renewal capabilities that update the certificates your web server uses and you are still able to securely access Tomcat through HTTPS without manual keystore creation or anything like that.I use a Synology DiskStation, which added LE support and a reverse proxy feature and I now have a fully automatic, one time setup solution I really like =)

Hi @vlott, I am running a SpringBoot application with embedded Tomcat and am trying to get it to work with Let's Encrypt, and searching through the forum came across your comment here. Did you post the steps you used? It would be super super helpful to us. I've installed certbot, and generated fullchain.pem & the PKCS12 file, as in some comments above, but am getting errors on the conversion to JKS (keytool gives me a BadPaddingException).

Did you take the route of just using the PKCS12 file with Spring-Boot/Tomcat and if so how did it go? Or did you use the reverse proxy route?

When prompted enter the domains that the letsencrypt server will call back to verify as per above

You should have a successful run and you should see the certificates in the /etc/letsencrypt/live directory

Create PKCS12 keystore (to be imported to jks later):sudo openssl pkcs12 -export -in /etc/letsencrypt/archive/yourDomain.com/fullchainx.pem -inkey /etc/letsencrypt/archive/yourDomain.com/privkeyx.pem -out yourDomain-cert_and_key.p12 -name tomcat (where fullchainx is fullchain1.pem, fullchain2.pem, etc., from the new certificate. This will be incremented every time new certs are generated. IMPORTANT! Use the fullchainx.pem instead of the certx or chainx or it won't work in Firefox)

29-Jul-2016 09:58:52.366 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
29-Jul-2016 09:58:52.384 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
29-Jul-2016 09:58:52.387 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-jsse-nio-8443"]
29-Jul-2016 09:58:52.742 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler ["https-jsse-nio-8443"]
java.security.KeyStoreException: Cannot store non-PrivateKeys
at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:258)
at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:302)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:90)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:245)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:839)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:558)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:65)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
29-Jul-2016 09:58:52.744 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: org.apache.catalina.LifecycleException: Protocol handler initialization failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1013)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
Caused by: java.security.KeyStoreException: Cannot store non-PrivateKeys
at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:258)
at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:302)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:90)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:245)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:839)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:558)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:65)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
... 13 more

... Maybe reproducing this can be done with uninstalling openssl... Just a guess...I just tried with tomcat 9.0.0.M9 and it gives completely different exceptions, but does not work neither.I want to rely purely on java, to not be affected by openssl security holes. So I created a virtual server with no openssl installed in it.

I just wanted to give everyone a heads up that the method @Coleman-rik documented is broken in 8.5.4, so if you are testing this out either use 8.5.3 or wait until the 8.5.5 is released with this fixed. Hopefully this will save some frustration as I just spent a few hours with 8.5.4!