Re: Hard time to verify ssl server certificate.

[Josef Wolf <jw...@raven.inka.de>]

On Mon, Feb 28, 2005 at 06:47:18PM +0100, Tobias Ringström wrote:
> Josef Wolf wrote:
> 
> >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?
>
> [I agree with everything Sussman has said, and I can confirm that neon 
> is only giving us the SHA-1 fingerprint, although it does not seem to be 
> documented anywhere.]
> 
> There are two problems here. The first is that Subversion does not 
> specify that it's displaying the SHA-1 fingerprint (although you tell in 
> a hackish way by the different fingerprint size), and the second is that 
> tinyca (which I know nothing about, btw) does not show you the SHA-1 
> fingerprint. I will work on making Subversion say that it's showing the 
> SHA-1 fingerprint, but you might want to contact the author of tinyca to 
> also show the SHA-1 fingerprint as well as the MD5 fingerprint.

Judging from the openssl documentation:

    -md2|-md5|-sha1|-mdc2
       the digest to use. This affects any signing or display option
       that uses a message digest, such as the -fingerprint, -signkey
       and -CA options. If not specified then MD5 is used. If the key
       being used to sign with is a DSA key then this option has no
       effect: SHA1 is always used with DSA keys.

it looks to me that md5 is the default not only for tinyca, but for openssl
too.  Therefore it looks to me as if tinyca is doing the right thing.  Thus,
IMHO, svn should print the sha1 digest only on DSA keys.  Since svn doesn't
have options to select _which_ digest to print, both (md5 and sha1) should
be printed.

BTW: From http://svn.webdav.org/repos/projects/neon/trunk/src/ne_openssl.c:

  int ne_ssl_cert_digest(const ne_ssl_certificate *cert, char *digest)
  {
      unsigned char sha1[EVP_MAX_MD_SIZE];
      unsigned int len, j;
      char *p;

      if (!X509_digest(cert->subject, EVP_sha1(), sha1, &len) || len != 20) {
          ERR_clear_error();
          return -1;
      }

      for (j = 0, p = digest; j < 20; j++) {
          *p++ = NE_HEX2ASC((sha1[j] >> 4) & 0x0f);
          *p++ = NE_HEX2ASC(sha1[j] & 0x0f);
          *p++ = ':';
      }

      p[-1] = '\0';
      return 0;
  }


This looks to me as if md5 is not implemented at all in neon?

> In the mean time, you should be able to generate an SHA-1 fingerprint 
> when you create the certificate using openssl using something like
> 
>    openssl x509 -in server.crt -noout -fingerprint -sha1

As I wrote earlier, this command don't work because svn stores the
certificate in a format that is not recognized by the openssl command. :(

-- 
No software patents!
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Hard time to verify ssl server certificate.

[Tobias Ringström <to...@ringstrom.mine.nu>]

Josef Wolf wrote:

>>[I agree with everything Sussman has said, and I can confirm that neon 
>>is only giving us the SHA-1 fingerprint, although it does not seem to be 
>>documented anywhere.]
>>
>>There are two problems here. The first is that Subversion does not 
>>specify that it's displaying the SHA-1 fingerprint (although you tell in 
>>a hackish way by the different fingerprint size), and the second is that 
>>tinyca (which I know nothing about, btw) does not show you the SHA-1 
>>fingerprint. I will work on making Subversion say that it's showing the 
>>SHA-1 fingerprint, but you might want to contact the author of tinyca to 
>>also show the SHA-1 fingerprint as well as the MD5 fingerprint.
>>    
>>
>it looks to me that md5 is the default not only for tinyca, but for openssl
>too.  Therefore it looks to me as if tinyca is doing the right thing.  Thus,
>  
>
I don't think the default value in OpenSSL is too interesting. One could 
argue that SHA-1 is a better default because it's at least supposed to 
be harder to fake. If you could point to an RFC or something that talks 
about a recommended or required fingerprint hash, that would mean a lot 
more.

>IMHO, svn should print the sha1 digest only on DSA keys.  Since svn doesn't
>  
>
It's a certificate, not a key, and I don't understand why the key type 
would have anything to do with the hash used to create the certificate's 
fingerprint.

>have options to select _which_ digest to print, both (md5 and sha1) should
>be printed.
>  
>
I agree that it would be useful to print both, but as I said in my last 
email, and as you confirmed in your reply, neon does not give us that 
option.

>>In the mean time, you should be able to generate an SHA-1 fingerprint 
>>when you create the certificate using openssl using something like
>>
>>   openssl x509 -in server.crt -noout -fingerprint -sha1
>>    
>>
>As I wrote earlier, this command don't work because svn stores the
>certificate in a format that is not recognized by the openssl command. :(
>  
>
Read my suggestion again. Instead of trying to extract a piece from an 
internal Subversion file (which is even created too late anyway) to 
generate an MD5 fingerprint, a much better method is for you to generate 
an SHA-1 fingerprint *when you create the certificate* and make that 
fingerprint available for manual verification (as well as the MD5 
fingerprint). You can do this today, and you don't have to wait until 
Subversion (if ever) presents an MD5 fingerprint as well as the SHA-1 
fingerprint.

/Tobias


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org