SimpleAuthority is a fully functional Certification Authority, or Certificate Authority (CA), that is designed to be very easy to use. It generates and manages keys and certificates that provide cryptographic digital identities for people and/or computer servers. These identities are designed to be used in other applications such as for:

• secure two factor authentication - using a technology like KeyVault for controlling access to Web resources
• secure email - for digital signing and encryption of email
• document signing - including PDF, Word and OpenOffice documents
• VPN access - to provide a much higher level of security than username/password access
• client SSL authentication - to control access to an online service such as a subversion repository or wiki
• server SSL authentication - to authenticate a Web server to people within a known community
• code signing - including Java archives, Windows executables, etc.

SimpleAuthority supports Windows, Mac OS-X and Linux platforms.

Unlike most CA products, SimpleAuthority does not require specialist PKI knowledge or supporting components like an external database. It is built on The Legion of the Bouncy Castle cryptographic library.

SimpleAuthority is free and contains no nag screens when used to manage up to 4 users. If you want to manage more users, or if you require advanced features, then you need to purchase a license.

SimpleAuthority contains no adware or other nasties.

Features

Certificate uses

SimpleAuthority generates standards-compliant keys and certificates suitable for use in almost any security application. These applications include, but are not limited to:

• Secure email - Microsoft Outlook, Thunderbird, Apple Mail
• Document signing - Microsoft Word, Adobe Acrobat, OpenOffice
• Client SSL - Firefox, Internet Explorer, Safari, Netscape, Camino
• Server SSL - Apache, IIS.

Certificates can be used to identify people and/or computer servers. Servers can be identified based on domain name or IP address.

Certificate management

Certificate status is highlighted using colour-coded "traffic light" icons (green, orange, red). This makes it easy to identify certificates that will expire soon or have already expired.

An iCalendar file can be generated and automatically updated containing certificate expiry dates. iCalender files can be read by numerous calendar applications including Apple iCal and Mozilla Sunbird.

Certificates can be published to an LDAP directory. This is an optional way of sharing certificates between users, for encrypting data from one user to another.

Certificate revocation and Certificate Revocation List (CRL) generation is supported, as an option for managing certificates that should no longer be trusted.

Identity files can be automatically and securely backed up. This allows for recovery of keys that may otherwise be lost, so that any data encrypted using these keys can be retrieved.

Certificate types and formats

Keys and certificates can be generated using PKCS#12/DER format (used by most applications), or PEM format, without or without a password. Certificate key lengths, certificate contents and signature algorithms are fully configurable.

Certificate Signing Request (CSR) files from external applications can be processed. This allows keys to be generated by other applications and for the public key to be included in a certificate.

Multi-level CA hierarchies and self-signed certificates are supported.

Interoperability

SimpleAuthority is highly interoperable with security products, corporate directories and legacy CA products.

Data can be imported in formats including:

• PKCS#12, DER, PKCS#7, PEM with password and PEM without password for certificates and identity files
• vCard or LDIF files for importing user information from an address book or directory
• PKCS#10 and PEM formats for Certificate Signing Request file processing.

Data can be exported in formats including:

• PKCS#12, DER, PKCS#7, PEM with password and PEM without password for certificates and identity files
• LDAP for publishing certificates to a directory
• DER and PEM for certificate revocation list (CRL) files
• iCalendar files for managing certificate expiry dates in calendar applications
• PKCS#10 and PEM formats for re-signing a CA certificate using an external PKI.

Modes of operation

SimpleAuthority can be run using:

• GUI application
• Command line interface
• Web application (servlet) interface.

Getting Started

The main window

The main window provides an overview of the users in your organisation and the status of their certificates.

• Users are listed on the left-hand side. These are the people or computer servers that use keys and certificates.
• The top right-hand side contains information about the selected user. These details are included in any new certificates that are generated for that user.
• The bottom right-hand side lists certificates that have been issued to the selected user.
• The coloured circles represent the validity status of issued certificates.

Generating keys and certificates

To generate keys and certificates:

1. Generate a Certification Authority (CA) - The CA is used to generate certificates for users. Normally you would only generate a new CA once for your organisation.
2. Generate one or more users - Each user represents a person or computer server that needs keys and certificates.
3. Generate certificates - When you generate a certificate (.cer) file you also generate a corresponding identity (.p12) file. The identity file is password protected and includes the private key as well as the certificate.
4. Distribute keys and certificates - The identity file and password must be sent to the user securely, because together they protect the private key. The best way to protect the private key is to send these components separately, e.g. email the identity file and SMS the password. The certificate is not sensitive so this file can be freely distributed.

File types

• PKCS#12 identity files (.p12 or .pfx) include both the user certificate and private key, and usually also the CA certificate. These files are protected (encrypted) by a password.
• DER-encoded certificate files (.cer or .crt) include a single certificate only.
• PKCS#7 certificate files (.p7b or .p7c) include one or more certificates, often a user and the CA certificate.
• PEM files (usually .pem) contain either a certificate or a private key. These files include printable characters only and most of the file is base-64 encoded. Private key PEM files may or may not be protected by a password.

Using keys and certificates

To configure an application for key and certificate use:

1. Import the user identity file into the application (or Operating System) key store. This requires entry of the password.
2. Import the CA certificate into the application (or Operating System) trusted CA key store, so that all certificates issued by this CA are automatically trusted.
3. (If necessary) Configure the application to choose the key and certificate to use.

When using keys and certificates in a security application:

• Your private key, from your identity file, is used for digital signing of emails, documents, etc., or for authentication using VPN, SSL, etc.
• Other people's certificates are used to encrypt data to them.
• Digital signatures are verified using the certificate of the person that created the signature. Note that the signing certificate is almost always automatically included in the signed email/document to make it available for this purpose.
• Your private key, from your identity file, is used to decrypt information that has been sent to you.

See Using Certificates for more details.

Generating a CA

How to generate a new CA

A Certification Authority (CA) must be generated before you can issue keys and certificates to users. This CA will be used to sign new user certificates.

To generate a new CA:

1. Select File > New CA..., or follow the prompt to generate a new CA when SimpleAuthority is first started.
2. Enter the details for the new CA and click OK.

1. (Enterprise license required) The CA certificate contents can be further customised by selecting Advanced Settings.... Refer to custom certificate types for details.
2. Random data must be collected to generate cryptographically secure keys for the new CA, and for the future generation of user keys. Move the mouse inside the Random data collection window and/or press random keys until the progress bar is filled.

1. Wait while the new CA keys are generated.
2. Enter a password to protect the CA keys.

1. The new CA has been generated. SimpleAuthority will be configured to use this new CA from now on. If you want to select a previously generated CA, you can change the CA selection under General settings in Options/Preferences (see below).

More complex CA hierarchies

The CA generated by the above procedure is self-signed. This should meet the needs of most organisations.

Some organisations may require a more complex CA hierarchy. For example, a self-signed CA may be used to generate one or more subordinate CAs, each of which issues certificates to a subgroup of users or to the same user group but for different purposes.

To generate a CA hierarchy, start by first generating the self-signed "Root CA". This Root CA should then be used to generate user identities for all subordinate CAs. Each of these subordinate CA users should be configured with the Certification Authority Certificate Type. These subordinate CAs can then be used to issue user certificates or even other CA certificates by changing the Certification Authority selection in Options/Preferences.

The Select CA dialog provides options for managing any CAs that have been created, and provides a way to easily switch between CAs for signing new certificates. This dialog can also be used to

• view a CA certificate - by double clicking on an entry
• generate a new self-signed CA
• import or export a CA from/to an external identity file
• delete a CA, and
• re-sign a CA certificate - using an external, third party CA.

Managing Users

Adding and removing users

SimpleAuthority maintains a list of users on the left-hand side of the main window. Each user represents an entity that can be issued certificates. This may be a person or a computer server.

New users can be added by clicking on the New User button, or by selecting File > New User.

Users can be deleted by highlighting the user in the list and selecting File > Delete User. However, it is recommended that users are not deleted until all certificates issued to that user have expired. This is to ensure that an accurate record is maintained of all valid certificates that have been issued.

User details are shown in the top right-hand side of the main window. These details can be changed by clicking on the Edit User button, or by selecting File > Edit User. Changes will be incorporated into any new certificates that are issued for that user.

The user details normally includes fields for Subject Alternative Name (Email Address by default) and Organisational Unit. Multiple values can be specified for these fields by separating values with a semi-colon. You can also prefix values for the Subject Alternative Name with EMAIL:, DNS:, IP: or URI: to override the default type and specify that the value is an email address, DNS value, IP address or URI, respectively. These values can also be mixed, for example DNS:myserver.priv;IP:192.168.0.1

The user details also includes a notes field that can be used to store comments about the user. These comments are not included in any certificates. The notes field can be shown or hidden by selecting View > Show/Hide User Notes from the menu bar.

The default settings for new user details can be changed in Options/Preferences.

New certificates

A new certificate can be generated for the selected user by clicking on the New Certificate button or by selecting File > New Certificate. The selected user must be active before a new certificate can be generated.

The new certificate contents will be based on the current settings for the selected user, shown at the top right of the main window. The certificate key length and signature algorithm is controlled from Default Certificate Settings in Options/Preferences.

Generating a new certificate involves generating the corresponding identity file (.p12 for PKCS#12 format). This file includes the private key, protected by a password. It is written to the output directory defined in the Identity Files section of Options/Preferences.

The identity file password can be randomly generated or it can be set manually. When a randomly generated password is used the password is written to a text (.txt) file alongside the identity file.

The Identity Files section of Options/Preferences also lets you control:

• if the certificate file (.cer for DER format) will also be written to the output directory - which can be useful if you need to distribute the certificate such as for encryption purposes
• the encoding format for new identity and certificate files - either PKCS#12/DER which is appropriate for most applications, PKCS#12/PKCS#7, or PEM with or without a password
• if a date stamp will be included in file names and key alias names - which can be used to help distinguish between old and new keys and certificates for the one user
• if a copy of the identity file should be retained for backup/future recovery purposes.

Once a new certificate has been generated, the identity file and corresponding password must be sent to the owner of the keys. For security reasons, these two pieces of information should not be sent together, and preferably not using the same communications channel. A recommended approach is to email the identity file to the user and to tell them or SMS them the password.

Certificate signing requests

SimpleAuthority supports the processing of Certificate Signing Request (CSR) files. CSR files can be generated by applications including IIS, Cisco routers and most Hardware Security Modules (HSMs). They include information for a requested new certificate including the certificate public key.

Select Import > Certificate Signing Request... from the menu bar to process a certificate signing request. You will be prompted to select the resulting certificate type and the certificate validity period. You will also be given the option of using the original CSR request to specify the user certificate details, or overriding these with custom settings.

Some certificate signing requests include certificate extensions that are requested for the final certificate. In these cases, an "Include extension requests from CSR" check box is provided for selecting whether the requested extensions should be included.

When a certificate signing request is processed, a new user entry is automatically created if required to register the new certificate with.

Certificate types

Certificates contain numerous fields, including extensions that provide additional information about a certificate owner and in some cases control what the certificate can and cannot be used for. To avoid having to work out what each extension does and which ones need to be used, SimpleAuthority uses "certificate types". The certificate type is effectively a template for what gets included in the certificate, as recommended by standards such as rfc5280 and as required to maximise interoperability.

The default certificate types are:

• General Purpose - suitable for secure email, VPN access, client SSL authentication, code signing and most other client applications
• SSL Server - designed to be used by a web server
• Certification Authority - intended for use by subordinate CAs (see CA hierarchies)
• Self-Signed - the same as General Purpose certificates, except these certificates are self-signed instead of being signed by a Certification Authority (not recommended for use unless you have a specific need for self-signed certificates).

Custom certificate types

(License required) Certificate types can be customised under Certificate Types in Options/Preferences, or by selecting Advanced Settings... when generating a new self-signed CA. The default certificate types (listed above) cannot be deleted or modified, however they can be copied to generate a new certificate type with customised settings.

Select View, Edit or Copy to open a dialog containing certificate type configuration settings.

The first few settings control the name of the certificate type, whether the certificate is self-signed or not, and the cryptographic algorithms to use. Following this are the user details that should be included in the certificate subject distinguished name, for identifying the owner of the certificate. The remaining settings relate to certificate extensions that may be included in the certificate. These control which extensions are used, whether or not an extension is marked as critical, and the extension contents.

From rfc5280, marking an extension as critical has the following effect:

A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

A summary of what each of the certificate extensions is used for is shown below. Refer to rfc5280 for further details.