⚠️ licensing certificates issue

Josh Boxer · October 21

For any customers using cloud licensing it is possible Aperture Data Studio will not be able to call out to Experian's licensing server with a Java PKIX error unable to find valid certification

Learn more about this issue and the 3 steps to take to correct this problem.

Background

A certificate is used to ensure calls to the licensing server are secure. This certificate used to be provided by Entrust until they sold their public certificate business to Sectigo, whose root certificate is not included in the trust store of Java. The resolution is to get the certificate and apply it, (which is a one time task unlikely to happen again in future).

A) Download the new certificate

Either from Sectigo OR it might be easier to get it directly from licensing server.

enter the API end point 'https://entitlement.saas.edq.com/api/v1/EntitlementCheck' into a web browser (the page will return error 405 as it cannot be opened in a browser)
from the site info button Export the certificate

You may need to manually add the ".crt" extension to the downloaded certificate file, as some browsers do not add this automatically

B) Apply the certificate

In Aperture, go to Settings > Communication, Upload the public cert file, enter any value as Alias, Add:

C) Refresh license information

Once certificate has been applied, go to top-right corner then 'About Aperture Data Studio (version)' then click 'Refresh license information'

Update - if this is not successful you might need to check that your firewall rules have not incorrectly categorized Sectigo (since they are still less well known than Entrust) as reported by another customer in the comments below

=====================================================

Other information if needed

'Client mode' - if the certificate cannot be applied immedidately then going to the Update license page and submitting your token will fail to connect successfully, which will trigger a checkbox to be shown to Temporarily use client mode:

It is also possible to switch to 'Client mode' in Settings > System > 'Client (via browser)'. These options require a somewhat recent version of Aperture Data Studio. For older versions there is a more manual option:

locate the Aperture Data Studio installation folder, default C:\Program Files\Experian\Aperture Data Studio <version>
Open the file named Server.Properties
Paste the following System.cloudLicenseFetchMode=CLIENT and save
Restart the Aperture server
Open license information and Refresh your license info (via your web browser)
(To revert back to Server mode remove the line from server.properties and restart)

This will allow you to Refresh license information via your web browser and can be a useful temporary resolution to any problems, but not recommended long term as it is less secure and requires a user to login regularly versus it just happening automatically behind the scenes.

Keytool - If there are issues accessing the UI to apply the certificate or if you have moved the location of your keystore then it is possible to apply a certificate using the Java Keytool utility bundled with Aperture:

Locate the keystore location, e.g.: \ApertureDataStudio\certificates\cacerts
Run the standard keytool command to import the certificate: keytool -import -trustcacerts -alias CloudLicense -file C:\certificates\entitlement.cert.crt -keystore cacerts
When prompted Enter keystore password:, enter "changeit".
When prompted Trust this certificate? [no]:, enter "yes".

Using the keytool will also work for Find duplicates standalone, the default keystore location will be "%JAVA_HOME%\lib\security\cacerts". Once located follow the remaining steps above.

If you are still having any issues feel free to ask below or contact our Support team

James T Sidebotham · October 21

In the UI I get the "Unable to retrieve license details from the license server" but in the logs I get:

jakarta.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Josh Boxer · October 21

That is indeed the certificate issue mentioned. Did you download the certificate from licensing server or from Sectigo? Can you try restarting the Server as you mentioned and if still seeing the issue then applying the certificate .crt file again

James T Sidebotham · October 21

I downloaded from https://entitlement.saas.edq.com/api/v1/EntitlementCheck - let me ask the team to restart the server, and I will update you.

Restart = same issue

James T Sidebotham · October 21

lic_error.txt

Here is what is shown from the "Show Error" option on the Refresh Licence page

The server logs show the following - is 'Error connecting to license server' a separate issue perhaps?

2025-10-21 18:25:42,020 INFO c.e.l.c.e.EntitlementStoreImpl [qtp636268525-149] Unable to fetch license details from the license server. Attempting to fetch from the local cache.
2025-10-21 18:25:42,938 ERROR c.e.l.c.e.EntitlementClientImpl [qtp636268525-145] Error connecting to license server.
2025-10-21 18:25:42,938 ERROR c.e.l.c.e.EntitlementClientImpl [qtp636268525-145] Catching
jakarta.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Ian Hayden · October 22

@James T Sidebotham This is still a problem with the certificate. Are you running on Windows or Linux?

Henry Simms · October 22

Hi @James T Sidebotham , can you check the location Data Studio is actually using for cacerts (the truststore)? You'll find this if you search for "-Djavax.net.ssl.trustStore" in the Aperture Data Studio Service 64bit.ini config file, which will be in the installation root directory (eg C:\Program Files\Experian), e.g.:

-Djavax.net.ssl.trustStore="D:\certificates\cacerts"

The default location for cacerts is in a folder named "certificates" in the root of the Data Studio database directory. So for example if your database is in D:\ApertureDataStudio, your default cacerts location is D:\ApertureDataStudio\certificates.

If your truststore location is set to something other than the default, you will need to either:

Modify the location of the truststore as defined in Aperture Data Studio Service 64bit.ini, and then copy your current cacerts file to that location or
Manually updated the cacerts file in the configured location using the keytool, eg:

"<path>\bin\keytool" -import -trustcacerts -alias <alias> -file <your cert>.crt -keystore "<path to>\cacerts"

KatriM · October 22

Is restarting the server needed for this or is restarting the services enough?

I've applied the steps above and refresh license information is stuck here:

Now it seems it was not stuck but it was actually able to do the license refresh. I selected Show error and then it showed that it had refreshed the license almost 10 minutes ago.

Josh Boxer · October 22

I did not need to restart any services for the certificate to take effect. Refreshing the license information should take less than 60 seconds. You would need to check the logs to determine if something is processing longer than expected.

Mike Pearson · October 22

I'm so glad I found this - we've been going mad trying to sort it!

James T Sidebotham · October 22

@Ian Hayden we are running on Linux

James T Sidebotham · October 22

@Henry Simms I passed on your instructions to the DevOps team.

James T Sidebotham · October 22

If i don't get this resolved before the 3 day deadline for the license, would I be able to continue using Aperture? Of course it's bad timing, and I have a lot of processing planned for Fri-Mon.

Ian Hayden · October 22

@James T Sidebotham Can you check to see if you have these lines in your docker-compose.yml file@

environment:
  JVM_OPTS: >
    -Djavax.net.ssl.trustStore=/opt/ApertureDataStudio/cert/cacerts

James T Sidebotham · October 22

@Ian Hayden those lines (-Djavax.net.ssl.trustStore=/opt/ApertureDataStudio/cert/cacerts) were not there, but DevOps added them and I tried again, but no luck.

Ian Hayden · October 23

@James T Sidebotham If everything is setup correctly this should work. Can you check that

the mapping exists for the cacerts file in docker-compose.yml,
that the server has been restarted using docker compose down (then docker compose up)
If you login to the running container, you can see the cacerts file in the location in the prior comment, and using keytool it contains the certificate you added, and the environment contains the JVM_OPS variable?

I appreciate this might be a lot - if you need help please reach out to support for assistance.

Futher note: If you use client-side licensing you can continue to use the product, it just requires manual updates for the license.

Thanks,

Ian

James T Sidebotham · October 23

We just had a long meeting with the DevOps team including monitoring our firewall in real time. It looks like the licence requests were getting specifically categorized by the firewall (as "Business-economic" or similar) and the rule for that category was blocking the traffic. The team changed the policy for that traffic category to "allow", and then I was able to successfully perform the 'update licence'.

The firewall had always had "entitlement.saas.edq.com" on the allow list, and no configurations had been changed since the last licence refresh so that confused the team. Thankfully, as of right now, the issue is resolved.

Thank you to Josh, Ian, EDQ Technical Support and my internal DevOps team for all the assistance provided in this.

⚠️ licensing certificates issue

Comments

Categories