Making SVN trust a new root CA certificate

If you’re using Subversion to connect to an HTTPS repository that’s signed by a non-standard root certificate — such as a certificate, for example — here’s how to do it on Linux or OS X. (Windows users: sorry, you’re out of luck. I haven’t developed on Windows since 1999, and I don’t ever want to go back. So the only way this post will ever be updated with Windows instructions is if someone else figures out how to do it and leaves a comment.)

  • First, download the certificate you’re interested in, e.g. “wget”. I suggest storing it in /etc/ssl/certs with an appropriate name, such as “cacert-root-ca.crt”. You’ll need to have root privileges (use “sudo”) to get write access to the /etc/ssl/certs directory.
  • Run “openssl md5 /etc/ssl/certs/cacert-root-ca.crt” and/or “openssl sha1 /etc/ssl/certs/cacert-root-ca.crt” and compare the results against the certificate fingerprint given on the website. The website you’re downloading this certificate from does give you its MD5 and/or SHA1 fingerprints, right? (If not, what the heck are you doing trusting a certificate you haven’t verified?!?)
  • Run “openssl x509 -text -in /etc/ssl/certs/cacert-root-ca.crt” to verify that the certificate’s data (company name and so on) looks correct.
  • If the above fails, add “-inform der” to the command above: maybe you accidentally downloaded the DER-encoded certificate instead of the PEM-encoded certificate.
  • If you have the DER version, you’ll need to convert it to PEM. Run “sudo openssl x509 -inform der -outform pem -in /etc/ssl/certs/cacert-root-ca.crt -out /etc/ssl/certs/cacert-root-ca.pem”. Note the “sudo” in front of that command: you’re writing to the /etc/ssl/certs directory, so you need to be root.
  • Now that you’ve got a certificate in PEM format and verified it, it’s time to edit your “~/.subversion/servers” file. In the “[globals]” section, add the line “ssl-authority-files = /etc/ssl/certs/cacert-root-ca.crt”. The “ssl-authority-files” option is a colon-delimited list, so if you already have something there and are adding the second certificate to it, use a colon to separate the two paths. If you’re adding a third certificate to the list, then you should already see the colon and be able to figure it out. :-)

I mostly figured this out from the “SSL Certificate Management” section of the Subversion book. Which I highly recommend reading, BTW.

I hope this helps someone else spend a little less time on Google figuring out how to trust a new root CA.


  • Ben Little says:

    Hi there, no longer has a crt file available, they have a cer file. Can I perform this same process with the .cer file?


  • Robin Munn says:

    This thread from the newsgroup says that .crt is the ASCII-encoded form of .cer — so I think the instructions would be pretty much unchanged for a .cer file. I see no options to the “openssl x509″ command that would tell it to expect a text-encoded and/or binary file, so I’m guessing it works with both.

    Let me know if you try it out and something doesn’t work.

  • David Davies says:

    On Windows, the SSL certificates are stored in the following directory:

    %USERPROFILE%\Application Data\Subversion\auth\svn.ssl.server

    When you accept the certificate on one machine, a file is created a file in this folder. That file contains the necessary key. Copy that file to the corresponding directories for other profiles (and on other systems), and Subversion and TortoiseSVN will already trust the certificate.

  • David Davies says:

    A more elegant approach than what I wrote above is to adapt the original article.

    First, you can get a DER-encoded version of the certificate from Internet Explorer. Just visit the repository in Internet Explorer (https://server/svn) and double-click on the lock icon. Click on the Details tab and then click the Copy to File button. Choose the first option, which should be to use the DER encoded binary X.509 format.

    Once you have exported this file, you can start at the second-to-last bullet in the original instructions above. You’ll need the openssl executable, but that’s not hard to find, and is probably already installed on the server where you’re running Apache with Subversion.

    On Windows, the “servers” file mentioned in the last bullet is located at %ALLUSERSPROFILE%\Application Data\Subversion if you want it to work for all users on the system. (If you only want the certificate to be installed for a particular user, you can modify the “servers” file at a parallel location in that user’s profile.)

    I found that using quotes in the path for my ssl-authority-files did not work, so you may want to omit them.

  • Norbert Wenzel says:

    Hmm, seems like TSVN 1.5 uses the Windows Trusted Servers. At least it accepted my self-signed cert, which is added to WinXP as trusted certification authority.

  • [...] This is in response to Making SVN trust a new root CA certificate.  I wanted to write this there, but I can’t send comments due to a site error. [...]

  • Per the pingback above, this info is also available on my site, but I’ve copied it here at Robin’s request.

    [quote from]

    This is in response to Making SVN trust a new root CA certificate. I wanted to write this there, but I can’t send comments due to a site error.

    @GEEK: Thanks for starting this discussion. The previous comment is the one that helped me get my post-commit hook working with VisualSVN Server on an XP box. I was writing a hook to update my web directory from the SVN repo on every commit.

    @Other contributors: Thanks for adding your comments which lead me to the right solution to properly make my server trust istself!

    Just to consolidate the steps:

    1. Hit the repo in IE at whatever its address is; e.g. https://server:8443/path/to/svn/
    2. It will tell you the cert is untrusted. Click view certificates.
    3. click Install certificate…
    4. hit Next
    5. select Place all certificates in the following store
    6. click Browse…
    7. select Trusted Root Certificate Authorities
    8. hit OK
    9. hit Next
    10. hit Finish
    11. hit Yes, OK, OK, YES!
    12. Start>Run>services.msc
    13. restart VisualSVN server service

    Now your hooks on that machine should not have any issue updating from itself.


  • Thanks for the article!

    With respect to verifying the fingerprint of the certificate, I believe your method isn’t quite right. That is, “openssl sha1 foo.crt” will return the hash of the contents of the file, whereas “openssl x509 -noout -in foo.crt -fingerprint” will return the fingerprint of the certificate contained in the file.

  • Allen Fuller says:

    I tried this; it doesn’t work for me.

    In my case, I have created my own root certificate (I am serving as my own CA). Then, I created a server certificate signed by the root CA certificate. I imported the root CA certificate into Firefox on another client, and it all works beautifully.

    But when I tell SVN, via the .subversion/servers file, to trust my root CA certificate as a certificate authority, it still says my server’s certificate is not issued by a trusted authority!

    Any clues as to what is going on?

  • Kasper says:

    Hello Robin,

    I noticed that you store the converted certificate as /etc/ssl/certs/cacert-root-ca.pem while you refer to it as ssl-authority-files = /etc/ssl/certs/cacert-root-ca.crt in ~/.subversion/servers.

    Is this intentional or an omission?

    With kind Regards,
    Kasper van den Berg

  • Marc Richter says:

    Hi There, I like your writing style and this article is of a very good quality to me. Thank you :)