I had to install a new Sectigo SSL certificate on my Windows server and now I get this message avax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. from older devices. This has always worked fine and still works on newer devices. I am using OkHttp and OkHttpUtils2 and have tried many things without success. I am currently working on an Android 13 device which fails but Samsung S23 on Android 16 succeeds. Any ideas would be greatly appreciated.
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Android Question Trust anchor for certification path not found. [Solved]
- Thread starter GeoffT660
- Start date
- Similar Threads Similar Threads
Thanks Erel. I had a feeling it was less secure. I did find this information that resolved the issue for my Sectigo certificate on my Windows Server.
There are cases where a Microsoft IIS and other Windows-based TLS servers will provide a certificate chain that is only trusted by updated clients. These servers do not have the ability to specify specific certificate chains to provide during the TLS handshake. These Windows servers will make their own determination of the certificate chain to serve, based on the trust-store of the server itself. In most cases, this trust-store is fully updated and therefore the server will not consider older clients - even when a CA has cross-certificates that provide trust for millions of older or legacy clients. As all public CAs are required to move to single-purpose hierarchies, and rotate root certificates more frequently - cross-certification is vital, but unfortunately IIS servers make this difficult to support."
To resolve the issue:
https://www.sectigo.com/knowledge-b...ficates-not-trusted-widely/kA0Uj00000051hpKAA
Run the script at the bottom of the article to change the registry to disallow the R46 cert. You may need to rename it via cmd using the command:
ren "filename" "new filename"
https://serverfault.com/a/238735
In IIS:
1) go to bindings
2) select https binding
3) "edit"
4) click "ok" button.
There are cases where a Microsoft IIS and other Windows-based TLS servers will provide a certificate chain that is only trusted by updated clients. These servers do not have the ability to specify specific certificate chains to provide during the TLS handshake. These Windows servers will make their own determination of the certificate chain to serve, based on the trust-store of the server itself. In most cases, this trust-store is fully updated and therefore the server will not consider older clients - even when a CA has cross-certificates that provide trust for millions of older or legacy clients. As all public CAs are required to move to single-purpose hierarchies, and rotate root certificates more frequently - cross-certification is vital, but unfortunately IIS servers make this difficult to support."
To resolve the issue:
https://www.sectigo.com/knowledge-b...ficates-not-trusted-widely/kA0Uj00000051hpKAA
Run the script at the bottom of the article to change the registry to disallow the R46 cert. You may need to rename it via cmd using the command:
ren "filename" "new filename"
https://serverfault.com/a/238735
In IIS:
1) go to bindings
2) select https binding
3) "edit"
4) click "ok" button.
Upvote
0