Version Control with Subversion - Login

Server Configurationserver really who it claims to be? The OpenSSL library does this by examining the signerof the server certificate, or certificate authority (CA). If OpenSSL is unable to automaticallytrust the CA, or if some other problem occurs (such as an expired certificate or hostnamemismatch), the Subversion command-line client will ask you whether you want to trust theserver certificate anyway:$ svn list https://host.example.com/repos/projectError validating server certificate for 'https://host.example.com:443':- The certificate is not issued by a trusted authority. Use thefingerprint to validate the certificate manually!Certificate information:- Hostname: host.example.com- Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT- Issuer: CA, example.com, Sometown, California, US- Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b(R)eject, accept (t)emporarily or accept (p)ermanently?This dialogue should look familiar; it's essentially the same question you've probably seencoming from your web browser (which is just another HTTP client like Subversion). If youchoose the (p)ermanent option, the server certificate will be cached in your privateruntime auth/ area in just the same way your username and password are cached (seethe section called “Client Credentials Caching”). If cached, Subversion will automaticallytrust this certificate in future negotiations.Your runtime servers file also gives you the ability to make your Subversion client automaticallytrust specific CAs, either globally or on a per-host basis. Simply set the sslauthority-filesvariable to a semicolon-separated list of PEM-encoded CA certificates:[global]ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pemMany OpenSSL installations also have a predefined set of “default” CAs that are nearlyuniversally trusted. To make the Subversion client automatically trust these standard authorities,set the ssl-trust-default-ca variable to true.When talking to Apache, a Subversion client might also receive a challenge for a client certificate.Apache is asking the client to identify itself: is the client really who it says it is? If allgoes correctly, the Subversion client sends back a private certificate signed by a CA thatApache trusts. A client certificate is usually stored on disk in encrypted format, protected bya local password. When Subversion receives this challenge, it will ask you for a path to thecertificate and the password that protects it:$ svn list https://host.example.com/repos/projectAuthentication realm: https://host.example.com:443Client certificate filename: /path/to/my/cert.p12Passphrase for '/path/to/my/cert.p12': ********…Notice that the client certificate is a “p12” file. To use a client certificate with Subversion, itmust be in PKCS#12 format, which is a portable standard. Most web browsers are alreadyable to import and export certificates in that format. Another option is to use the OpenSSLcommand-line tools to convert existing certificates into PKCS#12.Again, the runtime servers file allows you to automate this challenge on a per-host basis.Either or both pieces of information can be described in runtime variables:175