lightsail-network
Android. ExtCertPathValidatorException: Could not validate certificate
I used java stellar SDK on Android. Everything was fine until last week. For Android 5.0/5.1 I received error when I submitted transaction with ChangeTrustOperation:
javax.net.ssl.SSLHandshakeException: com.android.org.bouncycastle.jce.exception.ExtCertPathValidatorException: Could not validate certificate: Certificate expired at Sat Mar 07 02:59:59 GMT+03:00 2020 (compared to Wed Mar 18 10:02:26 GMT+03:00 2020)
This is only for Android 5.0 and Android 5.1. The time on device is correct. Requests to another server pass without error, so the problem is in Stellar SDK.
Stellar SDk version 0.14.0.
Here is stellar url: https://stellar-test.bdnodes.net?auth=uOodDQbSMN5ZpxClHUtqYCpJy904bEB4r5RmkzZmxnU
There seems to be something wrong with the website's certificate, please check this report.
Hope this helps you.
Okay. Thank you. It helped to understand what is wrong. But it seems that the issue is still in java stellar SDK. As I see there is OkHttpClient for server connection. What version of OkHttpClient lib is in java_stellar_sdk version 0.14.0?
I found that in OkHttpClient version 4.3.1 they knew about this bug (https://square.github.io/okhttp/changelog/#version-431)
Could it be fixed inside java_stellar_sdk?
I still believe that you should modify the configuration so that the server does not send a second certificate.
The Okhttpclient in SDK is 3.11.0, and I compiled an SDK with the latest version Okhttpclient, you can use it for testing(Please do not use it in production) or compile it yourself. stellar-sdk.jar.zip please unzip it.
Some links that might be useful: https://community.letsencrypt.org/t/ssl-test-gives-back-a-second-certificate/67519 https://discussions.qualys.com/thread/20154-two-ssl-certificates-appearing-on-scan-results-httpswwwssllabscomssltest
I still believe that you should modify the configuration so that the server does not send a second certificate.
Sorry, I work on client side so I don't know the specific of server side. Let me ask my backend developer if it is possible.
No, it means the sdk is not sending an SNI with the request; that testing site tries both with and without SNI
The stellar-main1/test1 certs have been renewed, but there are other issues here
Two cases
-
The client does not send SNI hitting either stellar-test or stellar-test1 will return the same stellar-test1 cert, so hitting stellar-test will result in a bad connect. This is a problem with the client, which should always send an SNI. If it does not, that is a bug in the client code. A workaround is to change the endpoint to stellar-test1, but if we ever replace it with stellar-test2 for failover, the client will stop working. This is why SNI is important
-
Client sends SNI Hitting either stellar-test or test1 will return the correct certificate.
@ire-and-curses Are you thinking the okhttp update broke the sdk, or might fix it? How does the timing work out?
@Synesso He is saying that the PR might fix it.
@AndroidVironitDeveloper Hi, would you mind helping us test it? I previously provided a Jar containing the latest version of the Okhttp client.
@overcat No problem. Yesterday I added your jar to my project but faced small problem with duplication of kotlin files from your lib with my project kotlin files and I was fail to build the project. Hope today I'll give some feedback
Okay, I finally rebuilt my project with @overcat Jar. Now for Android 5.0/5.1 I got such error:
Hostname stellar-test.bdnodes.net not verified: certificate: sha256/sjSIQ9LSikxlmN/2vXqyRbU5FLF8McaLjWuVK+RyWzo= DN: CN=stellar-test1.bdnodes.net subjectAltNames: [stellar-test1.bdnodes.net]
BTW, out backend developer sent a letter to Stellar Server support and received such answer:
Engineering notes:
- The expired certs have been renewed
- Customer client sdk should send SNI when accessing test.bdnodes.net or main.bdnodes.net
- If client cannot send SNI, should use test1/main1 as endpoint, not test/main. Note that this is not recommended since test1/main1 might be replaced by a different server if a failover is required
- Blockdaemon is investigating a permanent fix for 3
See above about SNI. Your client is still not sending one. If the updated jar was supposed to fix it, it did not.
That said, SANs have been added.
The client should still be fixed to send an SNI, however.
Yeah I'm not an SNI expert but I wondered if the new version of the library would send the right SNI automatically. Sounds like we have to pass an option or something.
https://github.com/square/okhttp/commit/75f73aeb64b0b1bcf9b7d158914b2e6e3dc4d1fb
Due to the long period of inactivity on this issue, I have decided to close it. If there are any further problems, let us reopen it.