I have a C# api running on a aws S3 with ubuntu. This API is use by a website, a windows application and a xamarin app deployed on Samsung android devices.
Since today 16:00 (paris time), the android part is not working anymore, I have a "trust issue". Clearly it seems to be related with DST Root CA X3 Expiration (No release on my side and the timing is perfect).
But I don't understand why...
- SSL certificate
I checked my SSL certificate and regarding let'sencrypt forums, I have one of the path base on "ISRG Root X1". The second one is base on "DST Root CA X3" (expired). I renew them anyway to be sure, but still the same certificate path. (and no problem for chrome to contact them).
- Internet with https is working
I can reach internet with a webview inside the app (to my website in https)
- Can't connect using restsharp
When I use RestSharp to contact my server, I have the trust issue.
My android devices are all the same: Samsung A7 tab, half up to date, the other half was update in august, all of them with Android 11. So theorically they are "not concerned" with this certificate expiration.
Can the problem come from Xamarin or RestSharp ? Maybe my server certificate ?
EDIT Ok half resolved.... If I go to the "Trusted Root Certificates folder" in my android device (don't know the exact name), If I disable the "Digital Signature Trust Co. - DST Root CA X3", it's working again !
Not a "real solution" since I need to update something like 150 devices... 2 options in my mind
- Can I force RestSharp to use a certificate more than another ?
- Is it just because Android know the expiration date is 30/09 and still use it because we are still the 30/09 and everythin will work Tomorow ?
CodePudding user response：
We’ve had similar issues today, unfortunately we were using older Amazon Linux on elasticbeanstalks. Upgrading to the latest Ubuntu build in your case should fix your issues.
The issue we had was the Amazon Linux version trusted certificate service was always adding the expired root certificate.
The reason restsharp is having problems is probably because it’s trying to do something like a curl request behind the scenes and is doing a handshake to verify the validity of the ssl cert when sending a request. The way it does this is checks it against certs that are trusted on the server, which includes the expired certificate.
See here for Ubuntu builds that have the latest certs upgrade https://ubuntu.com/security/notices/USN-5089-1
CodePudding user response：
I made an example of the workaround 1 on Cent OS 7 / openssl 1.0.2f.
https://gist.github.com/kujiy/67ef342170c4b0a36bb4bd9615ae2916
# fix the issue
cd /etc/pki/ca-trust/source/blacklist
wget -O dst.pem https://crt.sh/?d=0687260331A72403D909F105E69BCF0D32E1BD2493FFC6D9206D11BCD6770739
cd /etc/pki/ca-trust/source/anchors
wget --no-check-certificate https://letsencrypt.org/certs/isrgrootx1.pem
update-ca-trust
DOMAIN=$YOUR_DOMAIN
openssl s_client -connect $DOMAIN:443 -servername $DOMAIN | grep verify
DESIRED STATE
Files
$ ls -al /etc/pki/ca-trust/source/blacklist
-rw-r--r-- 1 root root 1200 Oct 1 16:48 dst.pem
$ ls -al /etc/pki/ca-trust/source/anchors
-rw-r--r-- 1 root root 1939 Oct 1 16:45 isrgrootx1.pem
Trust stores
$ trust list | grep -C3 ISRG
pkcs11:id=y