Subversion and Certificate Authorities
As I mentioned before we recently changed the URL of our subversion repository. We wanted to have a URL via SSL where our code could live for awhile. So I ventured over to InstantSSL.com and grabbed a 2 year certificate updated our DNS and life is good. No more of these right?
svn up
Error validating server certificate for 'https://svn.repository.com'
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: svn.repository.com
- Valid: from Mon, 09 Apr 2007 06:00:00 GMT until Thu, 09 Apr 2009 05:59:59 GMT
- Issuer: COMODO CA Limited, Salford, Greater Manchester, GB
- Fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
(R)eject, accept (t)emporarily or accept (p)ermanently?
This message is an annoyance at the user level and a huge waste of time when your have scripts or tools that start breaking because of it. The whole reason we did this move was to avoid having to press the 'P' button or worse yet have to remotely log into a remote machine and do the same. Very annoying.
Why is this happening?
It seems that in subversion under the hood uses openssl for its SSL support and openssl does not have COMODO as a valid certificate authority. A certificate authority is used as a digital way to bless a certificate as being good and valid which means that you are shaking hands with an entity that is who they say they are. Certificate Authorities are god-like entities that hold all the power behind a secure digital e-commerce eco-system. When the one you just shelled out 100+ bucks to is not trusted by the tool you use everyday all day it is a problem.
The Workaround
The wonderfully useful SVN Book talks about how to solve this issue at the client level.
This dialogue should look familiar; it's essentially the same question you've probably seen coming from your web browser (which is just another HTTP client like Subversion!). If you choose the (p)ermanent option, the server certificate will be cached in your private run-time auth/ area in just the same way your username and password are cached (see the section called “Client Credentials Caching”.) If cached, Subversion will automatically remember to trust this certificate in future negotiations.
Your run-time servers file also gives you the ability to make your Subversion client automatically trust specific CAs, either globally or on a per-host basis. Simply set the ssl-authority-files variable to a semicolon-separated list of PEM-encoded CA certificates:
[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
The trick is to translate this advice to Windows.
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
- Save this as <path>\comodo.pem - I put mine out on a network share so everyone on the team can access it.
- Open this file C:\Documents And Settings\<username>\Application Data\Subversion\servers in your favorite editor
- Edit the last line under the [global] section to say
ssl-authority-files = <path>\comodo.pem
Now conversations with your repository will not raise the ire of subversion thinking that you are talking to a non-trusted node out on the ether.
Comment to Comodo
If you want to roll with the big kids in the e-commerce big bad jungle you better work hard to address the issue that your certificates do not work out of the box with one of the fastest growing software development infrastructure tools on the market. This little snafu was a major pain in the ass and cost us more than we saved by going with you as our certificate authority so I will not be recommending you to others until this issue is solved.
Update
Comodo commented that they are selling intermediate CA certificates chained to other trusted "root" CA's. So the difficulty is not in the CA being trusted but the certificate consumer validating the chain of trust present in the certificate. I do hope that Comodo and other intermediate certificate providers work with OSS tools to make sure user experiences with their certificates are positive. Here is the Subversion project status page. It seems that in Subversion 1.5 there is this patch are this patch providing command-line switches slated to allow bypassing the invalid certificate warnings. Not sure this is as good as directly using the windows CryptoAPI as one commented noted.
