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

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?

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.

[quote from james.revillini.com]

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.

[/quote]

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.

%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.

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

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

Thanks