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 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 mail client supports LDAP directories for encryption certificates, Apple Mail does not.
To configure an email client:
- Import the user identity file into the mail client key store. This requires entry of the identity file password.
- Import the CA certificate into the mail client trusted CA key store, so that certificates issued by this CA are trusted.
- (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.
- Mail uses the macOS 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.
- 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.
- 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.
- 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.
- The CA certificate must be imported into the CAPI Trusted Root Certification Authorities store.
- Outlook includes options to specify which certificate to use for signing and encryption.
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.
- Word for Windows uses the Windows Microsoft Crypto API (CAPI) key store for keys and certificates. See Microsoft Outlook details above for more details.
- To apply a new digital signature, or to check the details of an existing signature, select Options > Security.
- Word 2004 for Mac does not support document signing. Signed documents can be opened and edited fine (except that editing breaks the signature), but signatures cannot be applied and they cannot be verified.
- PDF files use signatures differently from Word and OpenOffice files. Word and OpenOffice files have a signature that is separate to the document and applies to the whole document. PDF files include the signature field as part of the document itself, similar to a signature block on a paper document.
- PDF files must be created to include a Digital Signature field before they can be signed. This requires a copy of Adobe Acrobat Standard or Professional or equivalent.
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:
- 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.
- 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:
- Configure the server to require client SSL authentication.
- Configure the server to trust the CA that was used to issue client certificates.
- (Optional) Configure the server to also restrict clients based on an access control list, so that individual clients may be disabled from access.
- Require client SSL authentication using the
SSLVerifyClientdirective of the
- Export the CA certificate in PEM format from SimpleAuthority and configure Apache using the
- (Optional) Implement an access control list for clients using
AuthTypeand associated directives, where the
AuthUserFilefile includes a list of trusted certificates, one per line, like this:
/C=AU/O=Simple Authority/CN=Paul Cuthbert:xxj31ZMTZzkVA
- (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
SSLCARevocationFiledirective 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.
- Generate the server SSL identity using SimpleAuthority with the PEM (no password) identity file format.
- Use the
SSLCertificateKeyFiledirectives of the
mod_sslmodule to specify the SSL key and certificate files to use for server authentication.
- Use the
SSLRequireSSLdirective to turn SSL use on.
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,
- signed Java applets are allowed unlimited access to the local computer
- signed Windows executables can be downloaded from the Internet and run without displaying a security warning.
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.