TortoiseSVN failing validation after DST expiry

[unique_user]

My domain is: svn3.sliksvn.com

I ran this command: We run a Subversion hosting service over HTTPS (yes, Subversion still exists!) We are very happy with Let's Encrypt, but right now there are a few customers using TortoiseSVN (a Windows Explorer-integrated Subversion client) who are getting failures to validate the server certificate.

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.

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

As far as I know, TortoiseSVN bundles a new enough OpenSSL version to not exhibit the notorious validation issue.

It produced this output:

I'm not a Windows user, so I may be making mistakes, but it appears that the ISRG root is in my Windows' trust store. The DST root is also still there. I tried deleting the DST root, and disabling it, but this does not help the problem. The DST root seems to return anyway, so I cannot really delete it.

When I try to access the server using the default browser, the certificate is trusted correctly:

So, I am at a loss here for what could be wrong - and I'm fearing more customers running into this issue. So far, they have all been Windows users with TortoiseSVN.

My web server is (include version): Apache 2.4.49

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

My hosting provider, if applicable, is: self-hosted

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

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

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

Any help would be appreciated so I can provide a solution for the users having validation trouble!

[rg305]

Hi @unique_user, welcome to the LE community forum

@unique_user

The DST root seems to return anyway, so I cannot really delete it.

The good news is you must have a well connected system and it is automatically updating the roots for you.
If you no longer want to trust that cert, then move it into the "Untrusted Certificates" folder.
But that will likely do little to correct this VPN trust failure.
I suspect that the TortoiseSVN bundles some libraries that may need to be updated/patched.
You might find more about that on their site or through other information channels.
For the time being...
Form the menu choices shown in the error message, it seems that you could verify that fingerprint and trust it "permanently" (until the cert renews and fingerprint changes - LOL) to minimize the noise it creates.

[unique_user]

Hi @rg305, thanks so much for replying during this tumultuous time.

I tried moving the DST Root CA into the Untrusted certificates and rebooted, but as you expected, this did not have an effect.

I will try to get in contact with the TortoiseSVN developers to see if they have the same problem and hopefully we will find out the root cause of this validation issue. I will update this thread with my findings.

[rmbolger]

If TortoiseSVN relies on an embedded version of OpenSSL, it may not actually be using the Windows trust stores for certificate validation. There may be a file based trust store in the app's installation folder somewhere that doesn't have the ISRG Root X1 in it.

If I get some time, I can try and poke around on a test machine for it. But realistically, it may require the devs to release an updated version of the app.

[unique_user]

That is a good suggestion! They do bundle OpenSSL so maybe they use a custom CA certificates file.

I will dig around in its install directory and see if I can do some surgery there: check for ISRG Root and delete DST Root.

Stay tuned…

[rmbolger]

I also notice your server is using the "default" chain intended for old Android device compatibility.

---
Certificate chain
 0 s:CN = svn3.sliksvn.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

But I'm guessing you don't have a lot of old Android devices doing version control against your server. You may want to serve the shorter, alternate chain instead which tends to be more compatible with OpenSSL in general. I'm not familiar with acme_tiny.py or whether it supports alternate chains though.

[unique_user]

My company submitted a PR for acme_tiny to add alternative chain support, but the maintainer rejected it, at that point it seemed moot as the longer chain promised good compatibility. But we weren’t aware of the old OpenSSL bug. Maybe the shorter chain will give better results. Sounds like a great thing to try for me. Thanks so much!

[rmbolger]

I found this old Google groups thread from someone who was trying to get TortoiseSVN working against a server with an internal CA signed certificate.

https://groups.google.com/g/tortoisesvn/c/4Vs6WETe1Ew?pli=1

Here's the important bit:

O.K. we found out what the problem was. Apparently OpenSSL uses the Windows Root CA list to validate the chain, but NOT the windows intermediate CA list.
Windows will assemble the chain for you if you have a server certificate, and have the intermediate CA certificate in the Intermediate CA store and the root certificate in the Root CA store.

OpenSSL on the other hand will not assemble the chain. Thus the chain will be incomplete and not validate.

On the server we have chained server certificate with the intermediate certificate. The server now offers both the server and the intermediate to OpenSSL and OpenSSL is able to verify it using the Root CA certificate in the Root CA store.

I'm not sure whether this helps beyond confirming how Tortoise does cert validation. Their problem was due to the server not serving any chain which is not your current problem. I'd still probably lean towards trying to switch your server to the short chain though.

[unique_user]

There have been interesting comments on my TortoiseSVN mailinglist post:
https://groups.google.com/u/1/g/tortoisesvn/c/cVUXqh8VMh0

One server admin resolved the problem by switching to the alternate chain. That leads me to suspect that perhaps TortoiseSVN's bundled OpenSSL is configured in a way to fail. Removing DST should confirm this so I'm still going to play with that.

Thanks again to all for the good tips. I have learned a lot