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/06510feb-6e87-4139-9313-703a34b89142n%40googlegroups.com.
