Features and Technical Specification

Planned Features

The following list of features are planned for future versions of Halimede.

• Export keying material and certificates for use with OpenSSH.
• Export keying material and certificates to a SmartCard for authentication.
• Additional ciphers as they are made available.

Runtime Requirements

Halimede operates as a e4 RCP plugin designed to be operated in an Eclipse 2020-12 environment.

Halimede requires a minimum of a Java 11 environment and is tested with OpenJDK 11.

Design Rational

Halimede primarily has been designed for use by Software Developers to operate a small self-contained CA for use in generation of X509 Certificates and related keying material. It is also suitable for use by individuals in managing a small CA for personal use.

In searching for methods of running a CA, there are effectively two methods:

1. Run CA software designed for an Enterprise installation, eg Microsoft CA Server, DogTag, EJBCA, etc.
2. Build a set of scripts utilising OpenSSL.

The former is typically not suitable for small installations due to the additional requirements (typically a database server).

The latter is suitable for small installations, however has a steep learning curve in understanding how OpenSSL can be used to run a CA. Additionally, using OpenSSL assumes a solid grasp of X509 Certificates and all associated options.

Halimede has also been designed to use an open and well documented datastore format, allowing users to be be able to export any information from the datastore without the use of Halimede itself.

As Halimede has been designed for small installations, some features available with other CA software are not offered by default.

Supported Asymmetric Ciphers

Halimede supports the following Asymmetric Ciphers for use with X509 Certificates:

Datastore Format

Halimede uses a simple datastore format.

All issued Certificates and Keying material are stored in individual PKCS12 files (DES encoded), utilising AES256 for encipherment.

The base datastore format is:

<CA NAME> (Folder)
|- configuration.xml       (CA Configuration Information)
|- ca.p12                  (CA Certificate and Keying material - PKCS12 - DES)
|
|- CRLs                    (Folder containing all issued CRLs).
|   |- <issue num>.crl     (CRL - DES encoding)
|   |- <issue num>.crlprop (CRL Properties)
|   |- ....
|
|- Issued                  (Folder containing all issued Certificates)
|   |- <issue date>.p12    (Issued Certificate and Keying material - PKCS12 - DES)
|   |- <issue date>.prop   (Issued Certificate Properties).
|   |- ....
|
|- Requests                (Folder containing all external Certificate Requests).
|   |- <import num>.csr     (CSR - PKCS10 - DES encoding)
|   |- <import num>.csrprop (CSR Properties)
|   |- ....
|
|- Revoked                 (Folder containing all Revoked Certificates).
|   |- <issue date>.p12    (Revoked Certificate and Keying material - PKCS12 - DES)
|   |- <issue date>.prop   (Revoked Certificate Properties)
|   |- ....
|
|- Templates               (Folder containing all Templates).
    |- <create date>.xml   (Certificate Template)
    |- ....

Most items are stored in pairs, a PKCS12 file (or PKCS10 file in the case of a stored Certificte Request) and associated properties file. The properties file contains information that is used to populate the UI with key information, but does not contain certificates or keying material.

All PKCS12 files contain the full X509 Certificate path, therefore are largely self contained with keying material.

Each component is stored individually to ensure corruption to any individual file doesn’t affect the datastore as a whole. Additionally it allows each issued Certificate PKCS12 file to utilise independent passwords for protection.

Most XML and Property file formats are subject to change, however the properties contained should remain fairly static in nature.

The contents of the XML and properties file are largely self-documented.

For data stored in byte array formats, these are base64 encoded before storage. Some fields in particular Subject, KeyUsage and Subject Alternate Names are stored in ASN.1 format when required (base64 encoded).

Backup File Format

The default Backup file format is a simple Zip container with the Certificate Authority contents included. (All entries are compressed).

An additional manifest.xml file is included containing a complete manifest of all files, including file sizes and SHA512 digests for integrity.

The Zip container will also have a Zip Comment equal to the UUID of the Certificate Authority to add as an additional marker as a valid backup file.