1.12.2 running on Server 2019 with client certificate authentication not working

[SquishyZA]

What I am seeing:

1. Windows 2019 server fully updated
2. Install another CLI only SVN client and configure it to work with the SVN repo.
2.1. The SVN repo requires a SSL certificate to authenticate
2.2. Ensure that the configuration works
3. Download TortoiseSVN 1.12.2 64-bit and install with default options
3.1. Double check that TortoiseSVN uses the same server file as the CLI setup in step 2
4. Try to update using TortoiseSVN from the repo. It fails with an SSL error
5. Try to update with the original SVN CLI: It works

Work around:

Create a registry key: HKCU\Software\TortoiseSVN\OpenSSLCapi as a DWORD and set its value to 0. After doing this TortoiseSVN works.

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.

[Stefan]

On Thursday, August 8, 2019 at 6:16:32 PM UTC+2, SquishyZA wrote:

What I am seeing:

1. Windows 2019 server fully updated
2. Install another CLI only SVN client and configure it to work with the SVN repo.
2.1. The SVN repo requires a SSL certificate to authenticate
2.2. Ensure that the configuration works
3. Download TortoiseSVN 1.12.2 64-bit and install with default options
3.1. Double check that TortoiseSVN uses the same server file as the CLI setup in step 2
4. Try to update using TortoiseSVN from the repo. It fails with an SSL error
5. Try to update with the original SVN CLI: It works

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.

Stefan

 

[SquishyZA]

The cert is 2048-bit RSA with SHA256 hash, so probably not old ciphers.

I did import the cert, but possibly not in the right way. Is the import process documented anywhere? I just did the double click the pkcs12 file and accepted all the defaults import process.

[tho...@bafast.se]

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 Å.

[Andreas Hestermeyer]

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

[Thomas Åkesson]

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 Å.

--
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 tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/077e9730-00a5-41cf-8b70-712f46e8779dn%40googlegroups.com.

[Andreas Hestermeyer]

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

[Andreas Hestermeyer]

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

[Stefan]

On Saturday, March 11, 2023 at 3:00:59 PM UTC+1 a.hest...@gmail.com wrote:

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. 

not quite correct. p12 is supported, but old/deprecated/insecure ciphers are not anymore. So if you created your p12 file with such an old cipher, then it won't work anymore.

Also, TSVN is still built with OpenSSL 1.1.1.

All you have to do is get a new certificate for your server that uses a recent cipher.

And honestly, if you have a certificate on your server that's not supported by TSVN, then you should update it anyway, not just because of TSVN but because the encryption used isn't secure anymore.