PKI Products

Sodium CA is a GUI product, sharing many capabilities with other members of the Sodium family (the Sodium directory data management tool and the data synchronization product, Sodium Sync).

Sodium CA’s primary function is to sign certificates, which it will either create from scratch or take from incoming Certificate Signing Requests. Sodium CA maintains a database of certificates which it has issued, and can revoke certificates, publishing lists of revoked certificates as CRLs (Certificate Revocation Lists). Sodium CA works with a directory and manages information on the CA’s entry in the directory (in particular the certificate and CRL). It normally operates with a connection to the directory so that updates are always reflected in the directory.

Sodium CA in Operation

External Certificate Signing Requests (CSRs) are read from disk. Sodium generates CSRs in a manner that is straightforward to use with Sodium CA and is often used in tandem with Sodium CA. Sodium CA will process the CSR and generate a certificate, which will usually be published to the directory. Sodium can then complete X.509 identity creation from this certificate in the directory.

Sodium CA can manage one or more CAs. When a CA is created and initialized, there is the option to either generate a self signed certificate (for a root CA) or to generate a CSR which is sent to the parent CA to be signed. This enables a CA hierarchy to be easily built.

Sodium CA has a local database of all certificates issued by the CA. These are shown in the certificate view, with options to filter on status (active/revoked) and type (end user/CA).

Sodium CA gives the ability to revoke certificates, renew certificates (provide a new certificate for the same private key), and rekey certificates (provide a new certificate and X.509 identity (private key) for the same user).

Direct Generation of Certificates and Identity

Sodium CA enables an X.509 identity and Certificate to be generated for a selected directory entry. The X.509 private key and associated information is provided in a PKCS#12 file, for transfer to the entity needing it. This direct generation enables the CSR stage to be skipped, making it more convenient in many situations. Identities can be generated for end users and for Isode servers.

Sodium CA uses user attributes to set up appropriate X.509 Subject Alternate Names in the certificates, for example to support Internet Messaging, XMPP and X.400 applications. Direct use of information in the directory ensures consistency and helps to avoid errors. Setting correct Subject Alternate Name values is important for many deployments, and is an area that is particularly awkward with many CAs and toolkits.

Working with Other CAs

Sodium CA also enables generation of cross certificates for other CAs, and makes it very straightforward to set up the Cross Certificate Pair entries associated with this that are stored in the directory.

Along with handling subordinate CAs, this makes it very easy to set up a trust mesh with multiple CAs. This will be important in many deployments, for example to deal with CAs in peer organizations or to link a Sodium CA deployment used for specialized certificates, with a general purpose Enterprise CA.

Directory servers, such as M-Vault are an ideal repository for PKI information. There are three primary uses. The first is to store certificates associated with applications and users. This facilitates certificate lookup, which is particularly important to facilitate encryption services (e.g., S/MIME and STANAG 4406) where data will be encrypted with the user’s public key.

The second role is to store information associated with CAs (Certification Authorities), holding the CA certificate and cross-certificates that authenticate other CAs. This information is important in a complex PKI environment where multiple CAs are used with trust paths using cross-certification. By publishing this information in the directory, applications can perform Path Discovery using the information in the directory to determine the trust path.

The third role is in support of certificate checking. CAs will issue certificate status using Certificate Revocation Lists (CRLs) and delta CRLs, to indicate when certificates have been revoked. CRLs may be published in the directory and retrieved using LDAP. CRLs can also be retrieved using HTTP. OCSP (Online Certificate Status Protocol) provides a protocol to check the status of a single certificate, which can be more efficient than using (potentially large CRLs). M-Vault supports all three of these mechanisms (OCSP; CRL retrieval by LDAP; CRL retrieval by HTTP), which enables an integrated support for certificate checking. For further information see Isode whitepaper [Using OCSP, LDAP & HTTP for Certificate Checking in a Large Scale Distributed Environment and over Constrained Networks].

M-Vault provides flexible storage of end user certificate, CA certificate and CRL information. Sodium, Isode’s directory management tool, enables visualization and management of PKI information in the directory.

The above screenshot shows a CA entry in the directory with information about the CA’s certificate, CRL, and cross-certificate. When managing a complex PKI, it is important to be able to see PKI information and to import/export in a flexible way. In particular, it is useful to manage cross-certificates.

Sodium also provides information to verify certificates, showing the trust path that has been built and certificate verification by CRL checking (LDAP or HTTP) or OCSP. This is illustrated in the screenshot above with simple certificate checking.

More information on Sodium can be found on the M-Vault Data Management product page.