Using Certificates

This page is a "cheat sheet" for using keys and certificates in applications. Applications change, so please provide feedback if you find any errors or would like to contribute information.

Secure email

Secure email provides options to sign and/or encrypt email. Email signatures allow the person that sent the message to be securely authenticated to the recipient (so the "from" address can be trusted), and prevents the message from being modified in transit without breaking the signature. Encrypting an email protects against eavesdropping, such as by an ISP or systems administrator.

Secure email requires the email address in the certificate to match the email address for the mail account. If you have multiple email accounts, you need multiple certificates.

Email encryption requires your mail client to have access to the email recipient's certificate. The easiest way to configure this is for the intended recipient to first send you a signed email. Most email clients will then automatically keep a copy of this certificate for future encryption use. Alternative approaches are to manually import all user certificates into the mail client key store, or to publish these certificates to an LDAP directory and configure the mail client to retrieve certificates from the directory. Outlook and Thunderbird mail clients support LDAP directories for encryption certificates, Apple Mail does not.

To configure an email client:

  1. Import the user identity file into the mail client key store. This requires entry of the identity file password.
  2. Import the CA certificate into the mail client trusted CA key store, so that certificates issued by this CA are trusted.
  3. (If necessary) Configure the mail client to select the key and certificate to use for signing and encryption. Note that the same certificate can be used for both signing and encryption.

Apple Mail:

  1. Mail uses the OS-X Keychain key store, which is managed using Keychain Access. Double click on an identity (.p12) file to begin the process of importing it into the Keychain.
  2. The CA certificate must also be imported into the Keychain. The certificate (.cer) file can be double clicked to import it and then the trust settings changed to Always Trust.
  3. Mail does not include any preferences for secure email. Signing and encryption buttons will magically appear in the email compose window when everything has been set up correctly.

Microsoft Outlook:

  1. Outlook uses the Windows Microsoft Crypto API (CAPI) key store, which can be accessed via Internet Explorer Options > Content. Double clicking on an identity file starts the process of importing it into CAPI.
  2. The CA certificate must be imported into the CAPI Trusted Root Certification Authorities store.
  3. Outlook includes options to specify which certificate to use for signing and encryption.

Mozilla Thunderbird:

  1. Thunderbird has its own key store that the identity file must be imported into. This can be accessed via preferences/options.
  2. The CA certificate must be imported into the Authorities key store.
  3. Thunderbird includes account settings to specify which certificate to use for signing and encryption.

Document signing

Document signing helps protect documents from unauthorised modification. Signing a document provides a way of verifying that a document has not been altered, for example after it has been released to a client. Document signing can also be used to authenticate the author of a document, or in the case of PDF smart forms the person that completed the PDF form.

Microsoft Word:

OpenOffice:

PDF files:

VPN access

Certificates can be used in place of username and password authentication for VPN access. This provides a much higher level of security than password-based access.

Note that secure shell (ssh) does not use X.509 keys and certificates, therefore certificates generated using SimpleAuthority cannot (easily) be used for ssh access.

Client SSL authentication

SSL (or TLS) is normally used with a key and certificate on the server to authenticate the server to a client, however the server can also be configured to require the client to authenticate using a certificate. This is a secure way of providing services to specific clients over the Internet. It is especially useful for controlling access to Web services such as a company document repository (e.g. using subversion) or a wiki.

To configure a client's browser:

  1. Import the user identity file into the browser key store. This is the Windows CAPI key store for Internet Explorer, the Keychain for Safari, or Firefox's own key store.
  2. Import the CA certificate into the trusted CA key store, so that the user identity is trusted by the browser.

To configure a Web server:

  1. Configure the server to require client SSL authentication.
  2. Configure the server to trust the CA that was used to issue client certificates.
  3. (Optional) Configure the server to also restrict clients based on an access control list, so that individual clients may be disabled from access.

Apache:

  1. Require client SSL authentication using the SSLVerifyClient directive of the mod_ssl module.
  2. Export the CA certificate in PEM format from SimpleAuthority and configure Apache using the SSLCACertificateFile directive.
  3. (Optional) Implement an access control list for clients using AuthType and associated directives, where the AuthUserFile file includes a list of trusted certificates, one per line, like this:
    /C=AU/O=Simple Authority/CN=Paul Cuthbert:xxj31ZMTZzkVA
  4. (Optional) Use a certificate revocation list to manage untrusted client certificates, by generating the CRL using PEM format and including the Next Update field, and using the SSLCARevocationFile directive in Apache to reference the CRL file.

Server SSL authentication

Server SSL (or TLS) authentication involves using certificates to authenticate a server to a client but not vice versa. This is the most common way of authenticating a Web service to a browser.

Server SSL authentication requires the server certificate name to match the server domain name or IP address. The certificate type must also be set to SSL Server in SimpleAuthority.

The main problem with using your own CA such as SimpleAuthority for server SSL authentication is that the CA certificate will not be trusted by default by most browsers. This will cause a security warning to be displayed to the user. Aside from buying a commercial SSL certificate, the only solution is to import the CA certificate into the browser trusted CA key store.

Apache:

  1. Generate the server SSL identity using SimpleAuthority with the PEM (no password) identity file format.
  2. Use the SSLCertificateFile and SSLCertificateKeyFile directives of the mod_ssl module to specify the SSL key and certificate files to use for server authentication.
  3. Use the SSLRequireSSL directive to turn SSL use on.

Code signing

Code signing allows users of your software to verify that the code comes from a trusted source and that it has not been maliciously altered or accidentally corrupted.

Code signing can also be used to provide software with elevated privileges. For example,

The CA certificate must be imported into the operating system trusted key store before signed software is trusted.

Different software tools are used to sign code depending on the development technology. Java JAR files are typically signed using the jarsigner tool. Windows executables can be signed using signtool.exe, which is distributed as part of the Windows Platform SDK.