(Solved) JVM do not trust LE

1

Hi,

Maybe its not directly related with lets encrypt, I’m a bit new with server administration and some people here maybe could help me.

I’m was trying to get some data (with a java application) from another server with a lets encrypt certificate installed, so, I think JVM takes the “trust” from the OS, right?.

Ok, I tried a curl, and got this.

Trying to add the lets encrypt certificates to the “trust” of the OS, I placed those .pem in /etc/pki/tls/certs/

And ran $ sudo c_rehash

Now I’m not sure whats next, probably a restart would fix this, but it would be the last option. Any ideas about this?

thanks in advance. (sorry for my english)

2

For curl, you can download the latest set of trusted certs from links at curl - Extract CA Certs from Mozilla

curl https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt > cacerts

then

curl --cacert cacerts https://yourdomain.com

to test
It may be, of course, that this is an SNI issue (if your site is on the same IP as other hosts, and your old version of curl doesn't support SNI )

3

I keeps happening. Anyway, curl is just the test, the real problem happens in a java application that make requests to the same url. (allow java to accept a not-signed connection should not be an option)

4

This may be a different issue that the certs being accepted. In my test

centos5-test:~# curl https://node3.serverco.com/test
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: curl - SSL CA Certificates

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). The default
bundle is named curl-ca-bundle.crt; you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

centos5-test:~# curl --cacert cacerts https://node3.serverco.com/test
successfully got to node3

so ( for me ) doing the test on CentOS 5 with curl then that method works.

What domain are you trying to reach and connect to ? there may be a separate related issue with that SSL / site that is causing it.

5

I just tried your example and it works fine, but mine keeps failing.

edited

check and tell me if I works for you, maybe there is something uncommon with that certificate…

6

Do you use cloudflare to ‘protect’ your site ?

7

Yes, someone put cloud flare for some reason, but I thought that if the DNS cloud “is grey” it didn’t affected at all. so, what should I do?

8

Well, on the positive side, it’s not a problem of LE certificate unreliability. it’s the fact that you have cloudflare in the middle potentially affecting things ( it wouldn’t matter who’s signed the SSL certificate on your site). I suspect it affects you more as you are using older code ( centos 5) and possibly the java as well which doesn’t follow some of the more modern SNI etc.

I’m not a user of cloudflare, but there are a number of others on the forum here who do and may be able to help.

9

Java uses its own private store (not the system-wide one) and doesn’t currently trust the DST or ISRG root yet. To make sure your system trusts those roots, look at the “update-ca-trust” command.

Also, yes, if the cloud is not orange in the CloudFlare control panel, proxy is disabled for that DNS name.

10

Oooookay, you gave a good idea. This is what I’ve done:

I added the root certificate to the JVM truststore:

curl -O https://letsencrypt.org/certs/isrgrootx1.der
sudo /usr/java/default/bin/keytool -importcert -alias isrgrootx1 -keystore /usr/java/default/jre/lib/security/cacerts -file isrgrootx1.der

PS: The default password of the java truststore is “changeit”

didn’t work, so I added too the CA certificate:

curl -O https://letsencrypt.org/certs/letsencryptauthorityx1.der
sudo /usr/java/default/bin/keytool -importcert -alias letsencryptauthorityx1 -keystore /usr/java/default/jre/lib/security/cacerts -file letsencryptauthorityx1.der

Restarted again the java application and now it works. And just to finish (I promise), why the root certificate haven’t worked?

thank you so much everyone.

1 Like
11

You probably aren't sending the intermediate certificate on connection, or are sending the intermediate signed by the DST root. If you aren't sending the intermediate, there's a hole in your chain. If you're sending the DST-signed intermediate, it can't chain it up to a trusted CA, as you only added the ISRG root.

The letsencrypt-auto tool is using the DST-signed intermediates for chain.pem and fullchain.pem, so you probably should install the DST root too.

1 Like