SSL Cert Issue (cert storage)

dev support
1

Hey guys. We are getting the following error:

Unknown host: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

We have come across this in the past and can fix it using “sslCertificateInstall()”, but we wanted to know where cert info / trusted store is stored. Is it within Lucee, Java or Tomcat? We have updated Java and Lucee and still are getting the error.

Also, when we are on the topic, does sslCertificateInstall() create a new record or replace the previous record. Guess what I’m asking is can we use it over and over without being an issue.

Thanks in advance.

OS: Linux (amzn1.x86) 64bit
Java Version: 1.8.0_292
Tomcat Version: 8.5.23
Lucee Version: 5.3.8.189

2

in 5.3 it’s under C:\lucee\tomcat\lucee-server\context\security\cacerts

in 6.0 Lucee will default to using the jvm bundled cacerts

3

Thank you very much sir! Does sslCertificateInstall() write a new record or replace the previous record? Also, is there a way to list / check cacerts for a domain?

4
5

I like to point this out when I see the PKIX path building failed error that importing the cert is not always the best solution. I wrote up details here: How to Resolve Java HTTPS Exceptions if the server you are trying to connect to is not using a self signed cert, then the problem is probably that the server is missing the intermediate cert. You can do a quick test here: https://whatsmychaincert.com/ It is a very common configuration issue.

1 Like
6

Quick question related to this topic: Does the certificate apply to other domains? The company we are dealing with has setup a new cert on their DEV environment and are about to switch over their production certs.

Will we need to run sslCertificateInstall() again on the new domain? Is there anyway to see if the new authority is in another version of Lucee already? We are still running 5.3.8.189 as it is very stable for us.

I would love to not have to worry about this. Thanks in advance.

7

To make sure we have the latest cert authorities, what do I need to update? We are currently running:

Lucee 5.3.8.189
1.8.0_302 (Red Hat, Inc.) 64bit
Apache Tomcat/8.5.23

All very stable.

8

My recommendation would be to use Redhat’s cert management, not Lucee.

If the org in question is used to generating their own certs, they’re probably also used to placing their enterprise certs into the redhat trust anchor on the VM.

I.e.

This indicates how the trust anchors get generated into a java consumable cacerts

(whether you run the p11-kit commands yourself or not)

My recommendation would be to update the Redhat trust anchors to include your enterprise certs, and then use p11-kit to generate a comprehensive cacerts file. Either dump that cacerts file into the directory Lucee expects, or just symlink it. (because why manage anchors twice?)

1 Like
9

I agree with Joe’s response, but to answer your question, Lucee’s ca store is found here inside of the Lucee server context:

lucee-server\context\security\cacerts

You can use any tool you like to add certs to that file. Lucee will need to restart in order to pick those changes up. When you run the sslCertificateInstall() BIF, it’s just editing that cacerts file for you. The default password is changeit. You can use a CLI tool like keytool or a GUI like Portecle. It’s up to you.

10

Thanks. Currently under Lucee 5.3 the default certs are managed by the Lucee team, correct? Is there a way to check to see when the cert list was updated? I just want to make sure we are using the latest info and have time to test before the switch.

The new SSL certs are Sectigo certs.

11

Yes.

I assume you could find that file in source control and see when it was last modified. That doesn’t neccessarily tell you what certs are actually in it though.

Just open up the castore file in Portecle and look! You’ll want to use the thumbprint to verify if the root cert is in there (and all intermediate certs in the chain) since some certs can have similar names.

12

You should not expect Lucee’s store to be recent. This is an ongoing thing, last time I put through a PR I literally pulled the most recent cacerts from Debian.

But yeah, you can check Github.

Jun 2021 sound good? :smiley:

That’s why 6.0 doesn’t do this anymore. It wasn’t an automated update. There’s a bunch of lore/history in JIRA and in here. (With Pete and I involved, basically how having this sort of management in Lucee is almost always the wrong thing). You shouldn’t have a second thought about throwing it away and replacing it with the one the system generates. IIIRC most docker builds would throw away the packaged cacerts and symlink to the system store anyway.

13

We will update the cacaerts file for the 5.3.9 release tomorrow, thanks for the reminder all

https://luceeserver.atlassian.net/browse/LDEV-3965

1 Like
14

Is there a way to map Lucee to a different cacerts location? It would be great if this was possible. Would allow us to keep everything in one place.

15

You’re running linux. Make a symlink :slight_smile:

2 Likes
16

Windows Server 2012 on up supports symlinks as well. though most never use them

17

Alright boys.

I have everything setup and updated. Doing some testing, I’m still getting errors. Can someone try the following bit of code:

<cfscript>

    cfhttp(

            url = 'https://api.sandbox.ebay.com',
            method = 'get',
            timeout = 10,
            result = 'VARIABLES.httpResult'

    );
    dump( VARIABLES.httpResult );

</cfscript>

When I run this code, I’m getting the following error:

Unknown host: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

If it works, you will get a 404 error. LOL

Lucee Info

  • Version: Lucee 5.3.9.133
  • Servlet Container: Apache Tomcat/8.5.23
  • Java: 1.8.0_312 (Red Hat, Inc.) 64bit

Are you guys getting the same error? Any suggestions on how to get it to work? If it works on your box, what version of Lucee, Java and Tomcat are you running? Could Java or Tomcat be causing an issue?

NOTE: If we run sslCertificateInstall( ‘api.sandbox.ebay.com’ ); and reboot the box, everything works. However, on the live URL of eBay’s API they are not reporting the new cert. There is no way to install it until they switch over. I want to make sure everything is working and not need to run a script / code and have to reboot.

As always, thanks in advance.

18

My mac trusts the cert…
Does this show as trusted?
cmd:
openssl s_client -connect api.sandbox.ebay.com:443
Example snippets:

chain
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = "eBay, Inc.", CN = open.api.sandbox.ebay.com
verify return:1

<snip>

    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

(You could add -showcerts and get the actual PEM certs that are being sent from the server too…)

This means my system keystore trusts the cert. You should be able to do this from CentOS too - you should check if curl or wget to verify the cert, outside of lucee, is trusted by the system.

If you went and put the system cacerts in place, either in the JVM, or in a property, or by replacing lucee’s copy - and that system cacerts was generated from the same point, then… well… that tells us something.

if the cmd line works, and java/lucee doesn’t, then:

  1. The cacerts you copied isn’t the same as what the system was using (maybe install the cacerts script, maybe run update-ca-certificates or equivalent)
  2. The cacerts you copied to isn’t the one lucee is actually using
  3. Are you using a container/docker? Cuz if you are, you need to make sure the /etc/ssl or /etc/pki folder is bind-mounted if you want that stuff to persist, or make sure you have all the certs in a cacerts file that you’re somehow exposing to the container… it would add another layer to things. (i.e. i’d have you docker exec into the container, and try curl and wget and openssl INSIDE the container too)

Otherwise I’m not sure. I mean, I could fire up a commandbox instance, but it SHOULD honor my system certs. It’s worth knowing if your server (outside lucee) trusts the cert first.

19

what’s does this file look like?

Directory: C:\lucee\tomcat\lucee-server\context\security
Mode LastWriteTime Length Name

-a---- 30/01/2022 1:38 PM 108833 cacerts

20

That was the issue. Mine was from 2016. @joe.gooch messaged me yesterday and sent me his cacert file info. I ended up replacing it with the system cacert file. I just asumed that with the 5.3.9.133 update, the cacert file would be updated. Is there a way to force an update? I know that it would be bad if you had added certs, but in our case that would not be an issue.