The following sections provide an introduction to certificate-based authentication and describe how to configure Cornerstone to authenticate using a certificate.
Introduction
Subversion repositories commonly require a username and password to be provided by the user to verify their identity. The SSL/TLS protocol (upon which HTTPS is based) provides a more secure and flexible alternative: certificate-based authentication.
Certificate-based authentication provides several advantages over traditional password-based authentication, but the primary difference is that while password-based authentication relies on secrets defined and managed by the user, certificate-based authentication utilizes secrets issued and managed by the server or, more accurately, the certificate issuer or authority.
Other advantages of certificates include:
Certificates automatically expire at a given time.
Certificates convey additional information about the holder, such as organizational unit, contact information etc.
Certificates can’t be forgotten, as is the case with passwords (although they can be misplaced).
The private key contained within a certificate is of high cryptographic strength. This is not generally the case with user-defined passwords, which can often be guessed.
Passwords can be defeated using various techniques such as dictionary attacks that cannot be used with certificates.
Certificates are not without their disadvantages:
Infrastructure is required to manage the issuing of certificates.
Certificates require installation and management. Certificate-based authentication is often more complicated than password-based authentication.
Anyone in possession of the certificate’s private key is automatically granted access to the server. Certificates should therefore be distributed with care.
Authentication and Authorization
If an HTTPS server is configured to require a certificate then a client app such as Cornerstone will be unable to connect to the server unless the user can present a certificate that meets the server’s requirements. The enforcement of the requirement for a certificate serves two purposes:
Only users with a valid certificate (i.e. server-issued proof of identity) can connect to the server.
The user’s identity is given by or can be derived from the certificate’s contents.
Thus certificates can be used for authentication, i.e. verifying (or authenticating) the identity of the user.
Additional requirements can be placed on the client certificates to restrict access to those users authorized to access the server.
Examples of requirements commonly placed on client certificates include:
The certificate was issued by a certificate authority known to and trusted by the server.
The certificate has not expired.
The organization (or organizational unit) to which the user belongs (as defined by the certificate) is permitted access to the server or repository.
Thus certificates can also be used for authorization, i.e. to verify that the user is authorized to access the server.
Certificate Storage
A certificate used for the purpose of authentication must contain a private key—a secret known only by the issuer and the user—so the same care should be afforded the storage of certificates as passwords.
As with passwords, Cornerstone does not store certificates directly. Instead, the app delegates this task to the keychain, the standard system component responsible for managing the user’s credentials such as passwords and certificates.
Subversion is traditionally configured to use PKCS#12 certificate files stored at a location in the file system of the user’s choosing. Cornerstone ignores these settings, instead favoring use of the more secure and standardized keychain.
Unfortunately other Subversion apps such as the svn command-line tool, Xcode, Coda etc. do not provide support for the keychain and will need to be configured using the traditional Subversion configuration files.
Cornerstone needs to provide the certificate to Subversion whenever it connects to the HTTPS server. It therefore requires permanent permission to access not only the certificate, but also the secret it contains (its private key).
Cornerstone cannot use a certificate if it is not granted access to the certificate’s private key.
The Security Preference Pane
Cornerstone maintains a list of certificates for use with Subversion. This list is accessed through the Secure Sockets (SSL) tab located in the Security pane of the app’s Preferences window.
Open the Preferences window by selecting Preferences… from the Cornerstone menu.
Switch to the Security pane by clicking the associated toolbar item.
Activate the Secure Sockets (SSL) tab.
Click the add button under the certificate list and select Import Certificate from File…
A standard file panel is displayed. Select a certificate file and click Import.
Cornerstone can only use certificates that contain private keys for the purpose of authentication.
The most common file format for the distribution of certificates with private keys is the PKCS#12 format, commonly identified by the .p12 filename extension.
If the certificate file is password-protected (as is generally the case) then you will be prompted to enter the password to allow the certificate’s contents to be decrypted.
The certificate and its private key are imported into the keychain.
Cornerstone imports the certificate into the user’s login keychain.
If you wish to store your certificate in a separate keychain then you will need to import your certificate using the Keychain Access app.
The keychain will prompt to allow Cornerstone to access the certificate’s private key.
Click Allow to grant Cornerstone permission to access the certificate’s private key.
The certificate is added to Cornerstone’s certificate list.
Certificate Selection
When Cornerstone receives a request for a client certificate it must select the appropriate certificate for that server.
If no certificates have been added to the app’s list then a message is displayed, along with a link to the app’s Security preference pane.
If only one certificate has been added then Cornerstone will always attempt to use it and no additional configuration is necessary. For the majority of users a single certificate is sufficient.
However, some users will need to access multiple servers with separate certificates. In such cases Cornerstone will ask which certificate to use when connecting to a server for the first time:
Cornerstone will remember which certificate to use for the server and will not prompt again.
Changing the Certificate Used for a Server
Under certain conditions it may be necessary to change the certificate used for a server. For example:
The wrong certificate was selected.
The certificate expires.
A change in server policy necessitates the use of a different certificate.
Perform the following steps to change the certificate used with a particular server:
Open the Preferences window by selecting Preferences… from the Cornerstone menu.
Switch to the Security pane by clicking the associated toolbar item.
Activate the Secure Sockets (SSL) tab.
Select the certificate marked as currently used for the server.
If the certificate has expired:
Click the remove button to remove the certificate from the list. The keychain will prompt to remove Cornerstone’s permissions for accessing the certificate’s private key. Click Allow.
If the wrong certificate is used for the server:
Click the action button and select Forget Server Usage from the popup menu. The certificate is marked as Not currently used.
Add or import an alternative certificate as required.
Re-attempt the connection to the server. Cornerstone will ask which certificate to use for the server.
under the certificate list and select Add Certificate from Keychain… from the popup menu.
and select