You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Robert Denton <ro...@headsprout.com> on 2008/05/23 23:02:06 UTC

Error validating server certificate

Hi folks,

I have been attempting to set up the very excellent CPAN module SVN::Notify::Mirror, and things have been going very well. The goal is to use SVN::Notify in a hook script to mirror a portion of our repo on a windows development server.  What the module does is to logon to the remote server via ssh and issue an update.  So, while the hook lives on the svn server, it is actually the remote server that is updating.

Unfortunately, in testing, when I run the hook script manually it seems to work up until the actual updating needs done, and then I get this:

[root@svn hooks]# ./post-commit /svnserver/repos/testing/ 1008
Error validating server certificate for 'https://svnserver.domain.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.domain.com
 - Valid: from Fri, 16 Sep 2005 08:00:00 GMT until Tue, 16 Sep 2008 07:59:59 GMT
 - Issuer: (c)2002 Comodo Limited, Terms and Conditions of use: http://www.comodo.net/repository, Comodo Trust Network, Comodo Limited, GB
 - Fingerprint: (finger print was here)
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Killed by signal 2.

selecting p (for permanent acceptance) doesn't seem to do anything, and I am wondering if that is because the entity actually having a problem with the certificate is the remote server.  Oddly, logging onto the remote server, I can pull up the repo in a browser with not certificate complaints whatsoever.  

What can I do so that the remote server does not complain about the certificate?  I should not that the certs as well as the intermediate cert are correctly configured in the apache server on the linux based svn repository server.  Any ideas?

Robert   

Re: Error validating server certificate

Posted by John Peacock <jo...@havurah-software.org>.
Robert Denton wrote:
> selecting p (for permanent acceptance) doesn't seem to do anything, and 
> I am wondering if that is because the entity actually having a problem 
> with the certificate is the remote server.  Oddly, logging onto the 
> remote server, I can pull up the repo in a browser with not certificate 
> complaints whatsoever. 

Remember that on Windows, each user can have completely independent security 
settings, etc., so the only way to validate this fully is to attempt to perform 
any testing as the remote user that is performing the update, not as yourself.

> What can I do so that the remote server does not complain about the 
> certificate?  I should not that the certs as well as the intermediate 
> cert are correctly configured in the apache server on the linux based 
> svn repository server.  Any ideas?

The Comodo Trusted Root Certificate (Root CA) is apparently not installed in the 
default ca-bundle.crt that OpenSSL uses.  The reason you don't see that problem 
when logged in as an ordinary Windows user is that Windows ships with a large 
number of Root CA's already imported.

You are using Cygwin's SSL, but I don't know where the ca-bundle.crt file might 
live.  You can look under /etc (when logged in as the Cygwin user).  Then you 
just need to download the Comodo bundled cert file:

http://www.enterprisessl.com/ssl-certificate-support/cert_installation/ssl-certificate-index.html

and append that text to the ca-bundle.crt file that you found.  You probably 
already had to do this to install the certificate on the Subversion server itself.

However, if you can access the Subversion server without a certificate inside 
your network, you can also use the tunneling options of SVN::Notify::Mirror::SSH 
instead.  See the documentation for more details...

John

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