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 section in the configuration file then you should use it, otherwise you should create a new one.
If you need to trust several certificates then this can be done by placing them in a semicolon-separated list: Ssl-authority-files=/etc/ssl/certs/example.pem In the absence of any other sections or properties the content of the file would be: Similarly if there is an existing ssl-authority-files property that has not been commented out. Ssl-authority-files=/etc/ssl/certs/example.pem /etc/ssl/certs/another-example.pemĪlternatives Using the -trust-server-cert optionĪs 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. Security considerations Transferring the certificate 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. 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.
0 kommentar(er)
