On 04.06.2013 13:56, Lieven Govaerts wrote:
You are referring to a configuration where OpenSSL uses MS's CryptoAPI
to use the Windows certificate store. Never used it myself, but I see
that TSVN has implemented this, with an extra dialog to select a
client certificate if multiple were found.
I see no reason why that won't work with serf, we probably would have
heard about it if not.
So for Windows there's no problem, only for Mac & Linux we don't have
a smart card solution in 1.8.0 at this time.
Some information about this:
First, you have to compile OpenSSL with CAPI enabled. The default build
does not use this.
There are two build flags for the CAPI engine in OpenSSL. The first one
simply activates the engine, but it only works if the smartcard has only
one certificate that matches the request from the server. If there are
more than one matching cert on the card, then this won't work at all.
This actually happens a lot: expired certs that are still on the card,
or people having one cert for authentication and one for signing
documents - both of them matching the request info from the server.
A second build flag enables an UI: the CAPI engine shows a cert
selection dialog in case that there are more than one matching cert so
the user has to select the right one.
This works fine. But (and here's the big 'but'): there's no way to store
the selection. So for every session that cert selection dialog is shown.
And of course for longer sessions like a checkout, that dialog is shown
several times because there's also a timeout on how long such a cert is
valid and has to be re-read from the card (so you can pull the card out
of the card reader to stop the session).
So for automated checkouts or most operations with an svn client
(especially TSVN that uses multiple sessions for most commands), the
user has to select the certificate multiple times. That get's annoying
immediately and makes it practically unusable.
In TSVN 1.7 I implemented my own cert handling by reading out the
certificate from the cert store and passing that back to svn as the
pcks12 file. That way I could store the user selection and only have the
user ask once for the certificate.
Problem with this is that the certificate must be imported into the cert
store as "exportable". If it's not exportable, I can't get the cert and
pass it to svn as the pcks12 file.
So to get rid of these problems I had to patch the CAPI engine in
OpenSSL: I have to store the certificate the user selects in the dialog
in that CAPI engine, because only there can such certs be used without
having to export them: the CAPI engine uses the CryptoAPIs to only *use*
the certificates but never actually *see* them.
However, if the user selection is stored in the CAPI engine and the user
chose the wrong certificate, authentication will fail and keep failing:
there's no 'retry' in case the authentication fails and so no chance to
have the user select another cert. That's why I also had to export a
custom function from that CAPI engine in OpenSSL to clear the user
selection in case the authentication fails.
Since there are no retries for auth failures in this situation, if the
user makes the wrong choice the operation fails immediately and the user
has to restart the operation. But with my patched CAPI engine at least
the user selection can be stored and cleared if necessary.
This patched version of the CAPI engine in OpenSSL is already in use in
a company and works fine there.
In case you're interested: the patch for e_capi.c in OpenSSL is here:
https://tortoisesvn.googlecode.com/svn/trunk/ext/build/openssl.patch
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
