I digged a bit deeper on this and here is my analysis result and suggestion:
1. I understand SVN & TortoiseSVN work with P12-formatted certificates only. 2. This format is supported by OpenSSL only, if the "legacy" provider is activated. Easy to proof that reproducible on Linux: Install openssl 3.x and without activating the legacy-provider it won't support P12 (aka PFX) certificates. The "legacy" profider needs to be activated in openssl.cfn. 3. I understand TortoiseSVN's usage of OpenSSL isn't configurable. So there should be an option to switch on the legacy crypto providers OR it should be made configurable. I think there needs to be a config call with legacy provider enabled during startup of openssl. I am not very familiar with the TortoiseSVN code - so it would be fantastic if somebody knowledgeable would give it a try. Best regards, Andreas Andreas Hestermeyer schrieb am Samstag, 11. März 2023 um 13:47:54 UTC+1: > It works with older versions (putting the certificates in "servers" file - > that's correct. In the source code of TortoiseSVN I realize, that the > "legacy" provider does not seem to be supported. If I disable the legacy > provider for openssl on a Linux box, I get the same error as with > TortoiseSVN. So this might be the reason for it not working. Just a > suggestion. I can continue using the old version of Tortoise, but it woud > be great to get the newest version working. Cheers, Andreas > > Thomas Åkesson schrieb am Samstag, 23. April 2022 um 23:19:30 UTC+2: > >> Keep in mind that the issue is related to CAPI, i.e. when the cert is >> imported into the Windows certificate store. The OpenSSL interaction with >> Windows needs to be reimplemented using a more modern API, dropping CAPI >> (according to https://github.com/openssl/openssl/issues/8872). Will be >> interesting to see if that ever happens. >> >> You can always use one of the "traditional methods" of configuring a p12 >> and use the latest TortoiseSVN. >> - servers file >> - selecting the p12 when prompted by TortoiseSVN (and ask it to cache) >> >> You might need to disable CAPI in the TortoiseSVN registry setting if you >> need to have the same p12 imported (e.g. browser needs the same client >> cert). >> >> HTH >> Thomas Å. >> >> >> >> >> On 23 Apr 2022, at 18:14, Andreas Hestermeyer über TortoiseSVN < >> [email protected]> wrote: >> >> I realized today that TortoiseSVN switched to OpenSSL 1.1.1 (which does >> not support >= TLS 1.2 with client certificates, see >> https://github.com/openssl/openssl/issues/12859) in 1.10.4. Does anybody >> know, whether there is a solution coming up for this? Would be great to be >> able to use the latest TortoiseSVN. Cheers, Andreas >> >> [email protected] schrieb am Dienstag, 3. September 2019 um 20:19:58 >> UTC+2: >> >>> >>> >>> On Thursday, August 8, 2019 at 6:29:35 PM UTC+2, Stefan wrote: >>>> >>>> >>>> >>>> On Thursday, August 8, 2019 at 6:16:32 PM UTC+2, SquishyZA wrote: >>>>> >>>>> >>>>> Work around: >>>>> >>>>> Create a registry key: HKCU\Software\TortoiseSVN\OpenSSLCapi as a >>>>> DWORD and set its value to 0. After doing this TortoiseSVN works. >>>>> >>>>> >>>> Since the e_capi module of OpenSSL is not included in a default build, >>>> other svn clients usually don't have that OpenSSL module even built in. >>>> >>>> If the authentication fails if that module is enabled then that means >>>> that the clients don't have the ssl certificate imported into the windows >>>> crypt store. If they had, then it would/should work. >>>> >>>> >>>> >>>>> Other notes: >>>>> >>>>> I can reproduce the issue without step 2, so the other CLI does not >>>>> "interfere". It is just a useful troubleshooting step and stopgap while >>>>> TortoiseSVN was down. Older versions (1.10.?) did not have this problem, >>>>> but sadly I can not remember precisely which version I had before I >>>>> upgraded. >>>> >>>> >>>> It could also be that your ssl certificate uses old ciphers which are >>>> not included in the latest OpenSSL anymore. And TSVN uses the very latest >>>> OpenSSL version, where other svn clients often use the LTS version of >>>> OpenSSL which might have those old ciphers still enabled. >>>> >>>> >>> I am also seeing this issue. When the server is running OpenSSL 1.1.1 >>> with TLS 1.2 enabled there is no chance OpenSSL will successfully use CAPI. >>> The same client cert works fine when configures in servers file so the >>> issue is not old ciphers. >>> >>> I have found this issue: >>> https://github.com/openssl/openssl/issues/8872 >>> >>> Also olszomal is on target here: >>> https://github.com/openssl/openssl/issues/5847#issuecomment-469248292 >>> >>> Using the very latest OpenSSL has some risks. Can you recommend a >>> version of TortoiseSVN before upgrading to OpenSSL 1.1? >>> >>> Thanks, >>> Thomas Å. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "TortoiseSVN" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/tortoisesvn/k3gAWf9t8Us/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tortoisesvn/077e9730-00a5-41cf-8b70-712f46e8779dn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/tortoisesvn/077e9730-00a5-41cf-8b70-712f46e8779dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- 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/95f73f54-e4e6-41f7-b329-042c859ecc96n%40googlegroups.com.
