Hello, I searched for a workaround for this issue and the following worked for me (Windows 10). Go to https://letsencrypt.org/certificates/ and get the active Let’s Encrypt R3 certificate (https://letsencrypt.org/certs/lets-encrypt-r3.der). Add this certificate to your Windows certificate store. For this you just need to right click the file and select Install Certificate.
Best regards, Christian Tony Rietwyk schrieb am Montag, 4. Oktober 2021 um 04:47:48 UTC+2: > I assume that everyone is aware that a single certificate expiry has > caused issues all over the place since Thu Sep 30. See > https://www.theregister.com/2021/09/30/lets_encrypt_xero_slack_outages/ > > On Sunday, 3 October 2021 at 22:40:25 UTC+11 [email protected] wrote: > >> lördag 2 oktober 2021 kl. 22:11:55 UTC+2 skrev Walter Hop: >> >>> On 2 Oct 2021, at 20:44, Matthew Trescott via TortoiseSVN < >>> [email protected]> wrote: >>> >>> I don't believe anything changed on its own since yesterday; TortoiseSVN >>> was still giving errors this morning. However, I completed the certificate >>> chain switch (certbot renew --preferred-chain 'ISRG Root X1' --force-renew) >>> and Tortoise is now satisfied, although my old Android now complains :) >>> >>> >>> That is great! It’s a fair trade-off. I’m pretty sure that SVN clients >>> on old Android phones are extremely rare. I am definitely going to try the >>> alternate chain. Sadly our ACME client (acme_tiny) does not support it yet, >>> but we created a PR for it - it was rejected then, on the premise that it >>> wouldn’t be necessary. But now that the DST expiration has finally >>> happened, it turns out there are various corner cases where a sysop would >>> want to choose the alternate chain. >>> >>> So indeed the problem is that Tortoise is only checking whether the >>> highest certificate in the chain is a trust anchor, and not considering >>> that an intermediary could be a trust anchor as well. >>> >>> >>> That is important information. thank you. I don’t know the TortoiseSVN >>> source, but this MIGHT be caused by the way that the bundled OpenSSL is >>> configured. The OpenSSL version is new enough, and this behavior is >>> switchable. A patch was circulated on FreeBSD-security to change OpenSSL’s >>> default behavior so that it should succeed at the first verified >>> certificate and no longer bother looking at the expired DST root. >>> >>> --- crypto/openssl/crypto/x509/x509_vpm.c.prev 2021-10-01 >>> 09:16:51.753533000 -0400 >>> +++ crypto/openssl/crypto/x509/x509_vpm.c 2021-10-01 >>> 09:19:39.708106000 -0400 >>> @@ -537,7 +537,7 @@ >>> "default", /* X509 default parameters */ >>> 0, /* Check time */ >>> 0, /* internal flags */ >>> - 0, /* flags */ >>> + X509_V_FLAG_TRUSTED_FIRST, /* flags */ >>> 0, /* purpose */ >>> 0, /* trust */ >>> 100, /* depth */ >>> >>> Perhaps (but this is absolutely above my pay grade) a similar >>> configuration in TortoiseSVN’s build makes OpenSSL fail, and a change to >>> OpenSSL’s configuration might be a structural solution for TortoiseSVN. >>> >> >> Unless I'm mistaken, this flag is already set, at least in the "default" >> parameter section (as in the patch). It is not set in the "ssl_client" >> section but I don't know which section might be used by the TortoiseSVN >> connection. >> >> However as far as I understand the workaround is only required on OpenSSL >> 1.0.2. TortoiseSVN is, AFAIK, using OpenSSL 1.1.1. >> >> Kind regards, >> Daniel Sahlberg >> > -- 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/04588474-7d17-4ee5-9877-413b0743bbc0n%40googlegroups.com.
