We facing issue javax.net.ssl.SSLHandshakeException

My domain is: In our many server we getting the error while try to access our application .

android 7 and less version also In some case we getting same error in android 12 also

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:328)
at com.android.okhttp.internal.http.SocketConnector.connectTls(SocketConnector.java:103)
at com.android.okhttp.Connection.connect(Connection.java:143)
at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:185)
at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:128)
at com.android.okhttp.internal.http.HttpEngine.nextConnection(HttpEngine.java:342)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:331)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:249)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:437)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:114)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:245)
at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getOutputStream(DelegatingHttpsURLConnection.java:218)
at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:25)
at com.google.android.datatransport.cct.CctTransportBackend.doSend(CctTransportBackend.java:303)
at com.google.android.datatransport.cct.CctTransportBackend.lambda$bLAzIpNF4NtapXlUpPVGhzxyNT8(CctTransportBackend.java)
at com.google.android.datatransport.cct.-$$Lambda$CctTransportBackend$bLAzIpNF4NtapXlUpPVGhzxyNT8.apply(lambda)
at com.google.android.datatransport.runtime.retries.Retries.retry(Retries.java:54)
at com.google.android.datatransport.cct.CctTransportBackend.send(CctTransportBackend.java:372)
at com.google.android.datatransport.runtime.scheduling.jobscheduling.Uploader.logAndUpdateState(Uploader.java:146)
at com.google.android.datatransport.runtime.scheduling.jobscheduling.Uploader.lambda$upload$1$Uploader(Uploader.java:105)
at com.google.android.datatransport.runtime.scheduling.jobscheduling.-$$Lambda$Uploader$DXUaNZ7S78mHsDrcqc_9ECz1Ymg.run(lambda)
at com.google.android.datatransport.runtime.SafeLoggingExecutor$SafeLoggingRunnable.run(SafeLoggingExecutor.java:47)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:


Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

2 Likes

This has been talked about for years.
There is no surprise that any new roots are unknown and untrusted by such old operating systems.

2 Likes

This sounds like your devices don't trust Let's Encrypt's root certificate. We previously had a cross-sign from another CA, but that is expiring, so going forward, devices need to trust Let's Encrypt directly. However, it is possible there's something else wrong.

See Shortening the Let's Encrypt Chain of Trust - Let's Encrypt

What happens if you try to visit https://valid-isrgrootx1.letsencrypt.org/ on one of these devices?

4 Likes