Astea Mobile issue with new sectigo ssl certificate

Hi Christophe,

Can’t say that I have but a quick check with Copilot found the following:

1. Older systems or misconfigured servers missing the updated Sectigo chain

Several sources highlight problems caused by incomplete chain installation, especially after Sectigo's migration to new single‑purpose roots (R46/E46):

• Customers experiencing missing intermediate and root certificates causing chain errors, especially on older devices.
  [serverfault.com]

• Sectigo migration documentation warns that older chains are no longer usable and that all provided intermediates + cross‑signed roots must be installed.
  [help.rapid...online.com], [thesslstore.com]

• Failure to include the new R46 root is a common cause of chain failures during 2025–2026 rollout.

2. Java-based systems not trusting the new Sectigo root

One concrete issue (Jira defect PACZDATA‑7653) describes:

• Java runtime trust store too old → missing Sectigo Public Server Authentication Root R46
• Result: PKIX path building failed / unable to find valid certification path
  [PACZDATA-7...cate (R46) | Jira Prod]

This is directly connected to certificates issued under the OV R36 intermediate (which chains to R46).

Perhaps this helps?

Hi Christophe, 
I haven’t encountered this kind of issue in the past.  Do they get the same error in UAT?  Maybe try a different provider or reach out to the CA that provided it?  

 

The "Trust anchor for certification path not found" error occurs when a client (often Android) cannot verify the SSL/TLS certificate of a server because the root Certificate Authority (CA) is unknown, self-signed, or missing necessary intermediate certificates. It is typically resolved by ensuring the server sends the full certificate chain, using a publicly trusted CA, or correcting date/time settings on the client device.

This video provides a summary of the common causes and solutions for this error:

Common Causes

• Self-Signed Certificates: The server uses a certificate created by itself rather than a recognized CA, which is common in development or local environments.

• Missing Intermediate Certificates: The server is not configured to send the necessary intermediate chain to link its certificate back to a trusted root CA.

• Outdated/Incorrect System Time: The device date is set incorrectly, causing certificates to appear invalid.

• Android Trust Store: The CA that issued the certificate is not in the Android system's trusted root store.

• Android 12/13+ Restrictions: Newer Android versions have stricter policies regarding user-installed certificates and network security.

This video explains how to fix this error on Android, including how to check your date and time settings:

Troubleshooting and Fixes

• Verify the Certificate Chain: Use tools like SSL Labs or to check for missing intermediate certificates.

• Fix Server Configuration (IIS/Nginx/Apache): Ensure the full certificate chain (including the intermediate CA) is installed, not just the primary certificate.

• Update/Add Root Certificate (Android):

• User Certificate Store: If it is a private CA, import the CA certificate directly into the Android user certificate store. Network Security Configuration: Add a file to the application to trust custom CAs or user-added certificates, especially on Android 7.0 (API 24) and higher.

• Check Date and Time: Ensure the device date and time are accurate.

• Use Valid CA: Replace self-signed certificates with ones issued by trusted Certificate Authorities.

Hi Reid, Phil you are correct, after investigation the issue seems to be related to Sectigo's migration to new single‑purpose roots and for some Android mobile they don’t have this new certificaiton “root” in the Android truested root store.