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/30b9c13a-8af3-47b7-94af-9af3434b072dn%40googlegroups.com.

Reply via email to