Generating Certificates

Certificate status

The main SimpleAuthority window shows when certificates are due to expire soon. This is indicated by the coloured circles in the Status column of each of the two tables:

  • green means that the certificate is valid and is not going to expire soon
  • orange is a warning that the certificate is going to expire soon
  • red means that the certificate has expired and can no longer be used.

Circles that have a red cross over them (e.g. revoked certificate icon) represent certificates that have been revoked and can therefore no longer be used. See revoking certificates for details.

Expired certificates can be hidden from view by selecting View > Hide Expired Certificates.

The certificate expiry warning period is configurable in Options/Preferences.

screen shot

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.


screen shot

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.


screen shot

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 that can then be edited.


screen shot

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


screen shot

The first few certificate type settings control the certificate type name, whether the certificate is self-signed or not, and the cryptographic algorithms to use. The remaining settings relate to certificate extensions that may be included in the certificate. The settings control which extensions are used, whether or not the extension is marked as critical, and the contents of each extension.

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.

Extension name Recommendation Details
Authority Key Identifier Include, mark non-critical Includes a hash of the issuing CA public key, which is useful for security applications when constructing certificate chain paths.
Subject Key Identifier Include, mark non-critical Includes a hash of the certificate public key, which is useful for security applications when constructing certificate chain paths.
Key Usage Include, mark critical Specifies what the certificate can be used for.
Certificate Policies Include if needed Includes information about the organisational policy under which the certificate has been issued. Includes an Object Identifier (OID) that uniquely identifies the policy. Optionally also includes a URI to the Certification Practice Statement (CPS) document and/or summary text that is included in the certificate.
Subject Alternative Name Include if needed, mark non-critical Includes extra information about the user. Can be used to specify one or more Email Address, DNS Name, URI or IP Address values (see Managing Users for specifying multiple values). Must be included in the certificate to specify a user's email address if the certificate is used for secure email (S/MIME) purposes.
Basic Constraints Include, mark critical for CA certificates Identifies whether the certificate can act as a CA, i.e. issue other certificates.
Extended Key Usage Include only if use must be restricted Provides restrictions on what the certificate can be used for beyond the Key Usage extension. If this extension is included, then a certificate may only be used in a manner that is consistent with both the Key Usage and Extended Key Usage values.