On Feb 23, 2005, at 2:22 PM, Josef Wolf wrote:
> On Wed, Feb 23, 2005 at 11:38:59AM -0600, Ben Collins-Sussman wrote:
>>
>> On Feb 23, 2005, at 11:27 AM, Ben Collins-Sussman wrote:
>>>> $ grep ~/.subversion/auth/svn.ssl.server/07* | \
>>>> perl -ne 'print "-----BEGIN CERTIFICATE-----\n";
>>>> $x=64;
>>>> while ($x<length $_) {
>>>> substr($_,$x, 0, "\n");
>>>> $x+=65;
>>>> }
>>>> print "$_-----END CERTIFICATE-----\n";' | \
>>>> openssl x509 -inform PEM -fingerprint | \
>>>> grep Fingerprint
>>>>
>>>> to verify the certificate. IMHO, verifying a certificate should not
>>>> be _that_ hard ;-)
>>
>> To be fair, the svn client has a single generalized system for caching
>> authentication information. It's basically just a hashtable saved to
>> disk. So in this particular case, your "exported" cert is just one of
>> several pieces of information in the cachefile. The cache was never
>> designed to be "easily verified" by openssl tools... I'm not sure why
>> you're trying in the first place?
>
> Do you know a better way? tinyca gave me the md5, probably because
> this
> is the default with RSA keys. svn presented sha1. How do I verify
> that
> the certificate is valid when I have only md5 and svn presents me sha1?
> You suggest that the presented digest was not designed to be "easily
> verified". But when this is true, why is it presented at all?
>
No, I meant, the *cache* wasn't meant to be verified by openssl tools.
It's an internal svn format.
If we're talking about the interactive client-prompt that displays the
incoming server cert -- yes, absolutely, it shows the fingerprint for
verification. As far as I know, though, we're presenting the only
"fingerprint" that neon makes available to us. I wasn't aware that
there were two different types of fingerprints available.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 23 21:50:07 2005