Rate this page

Configure Subversion to trust a given SSL certificate

Tested on

Debian (Lenny, Squeeze)
Ubuntu (Lucid)


To configure Subversion to trust a given SSL certificate without prompting for confirmation


Subversion is a revision control system that supports the use of an HTTP-based protocol called WebDAV for client-server communication. By itself a connection of this type is unencrypted, however it can be used in combination with SSL if encryption is wanted.

When an SSL connection is established, the server identifies itself to the client by presenting an X.509 certificate. The client then determines which certificate authority (if any) issued the certificate, and whether that authority is trusted. If it is not then the client displays a warning, and asks the user whether the certificate should be trusted permanently, temporarily, or not at all. It also displays a ‘fingerprint’ derived from the certificate, which can be used to check the authenticity of the certificate by comparing it with a fingerprint provided by the issuer.

The main drawback of this process is the risk that the user will accept a certificate without checking it carefully enough. It is also a serious inconvenience if you wish to invoke the Subversion client from a non-interactive script. For these reasons, if the certificate can be transferred to the client machine by some other secure method then that is usually preferable to accepting the certificate during the SSL handshake.


Suppose you have administrative control over a machine that is used as a Subversion server, and a number of other machines that are used as clients.

You have created a self-signed SSL certificate which you have installed on the server, and which you now wish to install on the client machines. To this end you have copied the certificate onto each client machine using a secure method. Its pathname is /etc/ssl/certs/example.pem.


The certificate must be in X.509 format with PEM encoding. Certificates of this type are text files and begin with the line:


The certificate can be either:

Either way, the certificate can either be self-signed or signed by a certificate authority.


Subversion can be told to trust a certificate by setting the ssl-authority-files property within the [global] section of the servers configuration file. There are two locations where the Subversion client looks for an instance of this file:

In this instance the certificate is intended to apply to all users, so it is the system-wide configuration file that should be altered (/etc/subversion/servers); however if you do not have permission to do this then you may need to edit the per-user file instead.

If there is already a [global] section in the configuration file then you should use it, otherwise you should create a new one. Similarly if there is an existing ssl-authority-files property that has not been commented out. In the absence of any other sections or properties the content of the file would be:


If you need to trust several certificates then this can be done by placing them in a semicolon-separated list:



Using the --trust-server-cert option

As of version 1.6, the svn and svnsync commands have an option --trust-server-cert which causes any untrusted certificates to be accepted automatically when running non-interactively. Since this negates much of the benefit of using SSL it is usually best avoided, however there is at least one set of circumstances where its use can be justified: where the reason for using SSL is to secure access over an untrusted network, but access using --trust-server-cert will be over a trusted network.

Security considerations

Transferring the certificate

The certificate should be transferred to the clients using a secure method to ensure that it cannot be altered in transit, or if that is not feasible, it should be verified afterwards to check that no tampering has occurred. If you administer the clients remotely using a mechanism such as SSH or Puppet then it is a good idea to transfer the certificate using the same method (on the grounds that if the administrative channel has been compromised then so has the client generally).

See also

Tags: crypt | ssl | svn