Hi all, Followup from https://groups.google.com/g/tortoisesvn-dev/c/ZIzJPJjqW8A/m/yhtPaOX_AgAJ
It sounds like the fact that Microsoft IIS won't serve the old chain after it expires is more a limitation than feature (https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/). The old chain is still used to support older Android devices because Android does not enforce the expiration date on DST Root CA X3. Since I run mod_dav_svn on Apache, my only option (assuming this is the right solution for Tortoise compatibility) would be to remove support for these old Android devices by configuring Certbot to get a chain that ends with a self-signed ISRG Root X1 certificate (instead of an ISRG Root X1 certificate cross-signed by DST Root CA X3). Unfortunately there's no such thing as User-Agent detection with SSL/TLS... I will try changing the chain and report back. Best regards, Matt On Saturday, October 2, 2021 at 6:56:09 AM UTC-4 [email protected] wrote: > Hi, > > I have received similar reports in $DAYJOB but in a quite different setup > (Windows 2012, IIS, asp.net site, Apple clients). I'm not sure if you are > hosting Subversion on Windows or Unix (using Unix in a broad sense > including Linux and *BSD). > > For me the solution was to restart the server. It seems that Windows was > serving a certificate including both the old chain rooted in DST Root CA X3 > (which is expired) and the new chain rooted in ISRG Root X1 (however the > latter chain without one of the intermediate certificates). Apple clients > choose the old chain and displayed errors while Windows clients used the > new chain and downloaded the intermediate certificate as needed. After the > restart, the server is (probably) only serving the new chain. > > It is possible that TortoiseSVN is displaying the same behaviour as the > Apple clients if the server is serving the old certificate chain. > > There is also a thread in the group TortoiseSVN-dev ( > https://groups.google.com/g/tortoisesvn-dev/c/ZIzJPJjqW8A) regarding this > problem. > > I found a blog article ( > https://borncity.com/win/2021/09/30/lets-encrypt-zertifikate-rger-mit-windows-sophos-utm-macos-ios-30-9-2021/) > > containing a collection of different applications having problems. This > contained the suggestion to restart the server. > > SSL Labs has a good SSL server test (https://www.ssllabs.com/ssltest/) > where you can see the chains sent from the server. On svn3.sliksvn.com > (as well as the site mentioned in -dev) there are two Certification paths. > On my $DAYJOB site there is only one chain after the server restart (I > don't have a copy of the test I did yesterday but I'm quite sure that it > had two chains). > > Hope this gives some input. Please report back since this is probably > affecting more users. > > Kind regards, > Daniel Sahlberg > > > lördag 2 oktober 2021 kl. 11:44:29 UTC+2 skrev Walter Hop: > >> Hello all, >> >> We run a Subversion service over HTTPS, and we use Let's Encrypt to >> provide HTTPS certificates. >> >> Traditionally this worked perfectly, but since October 1st, some of our >> customers using TortoiseSVN are now getting a HTTPS validation error such >> as: >> >> "Certificate validation failed >> Error validating server certificate for https://svn3.sliksvn.com:443: >> Unknown certificate issuer. >> Fingerprint: 52:2C:0B:1D:1A:CD:B7:E4:F9:B8:52:7C:C3:53:37:CB:01:D2:70:7C >> Distiguished name: R3, Let's Encrypt, US >> Do you want to proceed?" >> >> Example screenshot: >> https://aws1.discourse-cdn.com/letsencrypt/original/3X/4/c/4c86de3dafa73b97b19696857e8d253b740aeef4.png >> >> The timing is not a coincidence. There was a change in Let's Encrypt's >> validation as of 1 October: >> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ >> >> In short, Let's Encrypt certificates were trusted by operating systems >> based on two root CAs, "ISRG Root" (Let's Encrypt's new root CA) and "DST >> Root CA" (which already existed and is more widely trusted on old devices). >> >> As of yesterday, "DST Root CA" has expired, leaving only the "ISRG Root" >> as a trust provider. All major operating systems including Windows ship the >> ISRG Root in their trust store since years, so the DST expiry has been a >> non-event for most use cases. >> >> However, we have a small number of TortoiseSVN users who are reporting >> that validation of Let's Encrypt HTTPS certificates no longer works >> currently, giving the error above. >> >> The users reported that they have Windows updates enabled, so their >> machines should have the newest root certificates. >> >> I installed a clean Windows 10 virtual machine and setup TortoiseSVN to >> investigate the problem myself, and I can reproduce it with latest, >> updated, Windows 10 and latest TortoiseSVN, getting the same validation >> error. I have verified that my Windows has the "ISRG Root X1" in the >> certificate store, and Edge can connect normally to the HTTPS site - it is >> specifically TortoiseSVN that fails to validate. >> >> I am not a Windows user myself, but it is my assumption that TortoiseSVN >> uses the system's certificate store. Therefore it should still trust Let's >> Encrypt certificates, and I am puzzled why the HTTPS validation fails in >> some cases. >> >> As can be seen on Qualys SSL test, our server is sending the correct >> (default) Let's Encrypt certificate chain, leading up to the ISRG Root X1: >> https://www.ssllabs.com/ssltest/analyze.html?d=svn3.sliksvn.com&hideResults=on >> >> Therefore my question is, could there be an issue with TortoiseSVN >> itself, leading it to not successfully trust Let's Encrypt's new root >> certificate? >> >> Any help would be appreciated. I would be happy to test, since I have a >> reliable reproduce. >> >> If someone is interested in testing HTTPS in a live scenario, we provide >> free Subversion accounts, one can be created here: >> https://sliksvn.com/signup/ >> >> For now, I have advised our users to verify the fingerprint and accept it >> manually - fortunately that option is there, so the users can keep on being >> productive... Only every few months, our certificate will renew, and I >> expect the users will get the error again. >> >> Kind regards, >> Walter Hop >> Slik BV >> >> --- >> >> TortoiseSVN version and bundled libraries info: >> >> TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02 >> ipv6 enabled >> Subversion 1.14.1, -release >> apr 1.6.5 >> apr-util 1.6.1 >> serf 1.3.9 >> OpenSSL 1.1.1i 8 Dec 2020 >> zlib 1.2.11 >> SQLite 3.29.0 >> >> -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/7d825408-afc1-4cf4-9a8b-444ea8535425n%40googlegroups.com.
