When connecting to Subversion repositories using SSL connections the SVN client checks the server certificate if it is not expired, if it’s host description matches the host of the repository and if the authority which signed the certificate is trusted.
If the certificate fails to comply with any of the above rules the SVN client will respond with a message such as this one:
Error validating server certificate for ‘https://hostname:443′:
– The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
– Hostname: hostname
– Valid: from Tue, 16 Feb 2010 16:58:39 GMT until Fri, 14 Feb 2020 16:58:39 GMT
– Issuer: company.com, London, Berkshire, GB
– Fingerprint: d5:4e:d8:12:33:12:a5:f1:18:91:77:40:c4:77:3b:0b:f8:51:71:cd
(R)eject, accept (t)emporarily or accept (p)ermanently?
The certificate can still be accepted permanently manually. It may not be a solution if SVN commands are issued by non interactive processes. For example a PHP script run by apache trying to export a branch from the repository.
Certificates signed by trusted authorities such as Verisign should not have any problems. But self signed certificates will not be recognized by the SVN client which in turn will respond with the response above. Self signed certificates can be be made trusted by the SVN client by using the ssl-authority-files configuration option:
ssl-authority-files = /home/void/.subversion/company.crt
The configuration file named servers which holds this configuration option can be stored in multiple locations on the filesystem. First the Subversion client will try to look for it in the home folder of the user that is executing the SVN command. Users such as apache will most likely not have a home folder. In such cases SVN tries to look for the servers file in the /etc/subversion directory. It may or may not exist depending on the OS distribution flavour. For example it exits on Ubuntu but does not exist on CentOS a flavour of RedHat.