Configure Subversion to trust a given SSL certificate
Content |
Tested on |
| Debian (Lenny, Squeeze) |
| Ubuntu (Lucid) |
Objective
To configure Subversion to trust a given SSL certificate without prompting for confirmation
Background
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.
Scenario
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.
Prerequisites
The certificate must be in X.509 format with PEM encoding. Certificates of this type are text files and begin with the line:
-----BEGIN CERTIFICATE-----
The certificate can be either:
- the one that the server is using (which must match the domain name of the repository), or
- one from higher in the chain of trust (by which the server certificate has been directly or indirectly signed).
Either way, the certificate can either be self-signed or signed by a certificate authority.
Method
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 the system-wide configuration area (
/etc/subversion/) and - in the per-user configuration area (
~/.subversion/).
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:
[global] ssl-authority-files=/etc/ssl/certs/example.pem
If you need to trust several certificates then this can be done by placing them in a semicolon-separated list:
[global] ssl-authority-files=/etc/ssl/certs/example.pem;/etc/ssl/certs/another-example.pem
Alternatives
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).