This page describes security infrastructure components that are used by many of the Isode products. Along with the pages on SASL (Simple Authentication and Security Layer) and TLS (Transport Layer Security) this describes the infrastructure of the Isode products that use cryptography.

X.509 and Strong Authentication

X.509 describes an approach to providing and managing authentication using asymmetric cryptography, generally referred to as Public Key Infrastructure (PKI). X.400 and X.500 defined authentication mechanisms uses X.509 PKI, which these standards referred to as "strong authentication". Isode uses the term strong authentication to mean authentication based on X.509 PKI. This is common usage of the term, although it is sometimes used to refer to other technologies.

X.509 is used by Isode's products. Isode's security infrastructure includes:

  • Libraries to enable applications to perform X.509 verification in support of strong authentication.
  • Encrypted storage of private key and certificates in a PKCS#12 format file.
  • Certificate and CRL cache.
  • Infrastructure common to various Isode management tools, that enable setting up of X.509 credentials for a client or server, and interaction with a Certification Authority (CA) using PKCS#10 Certificate Signing Requests. This enables use of Isode products with most CAs, including the Isode Sodium CA.
  • Sodium enables generation of PKCS#10 CSRs for objects stored in the directory, to facilitate setup of X.509 configuration. Sodium and Sodium CA are designed to work closely together.

X.509 is used in many of Isode’s products and includes support for the following protocols and services.

  • X.400: P1 strong authentication and X.400 end to end services for content integrity, message origin authentication and message sequence integrity.
  • X.500: Signed Operations and Peer Authentication for DAP, DSP and DISP.
  • LDAP
  • SMTP, IMAP and POP.
  • XMPP C2S and S2S protocols.
  • S/MIME signing and encryption

Authentication used with Transport Layer Security

Transport Layer Security (TLS) is an Internet Standard for providing data confidentiality and provides strong authentication using X.509 Certificates. Internet messaging and directory protocols make use of SASL to provide authentication services. When X.509 based authentication is used by messaging and directory protocols, the SASL authentication is made available to the application by the "SASL External" mechanism. This means that the application authenticates within the SASL framework, but uses the underlying TLS X.509 authentication to provide the authentication service. TLS provides two X.509 based authentication mechanisms:

  • Client Authentication. Where a client application is authenticated by a server (e.g., For an LDAP server to verify the identity of a client).
  • Server Authentication. Where the identity of a server is authenticated by a client (e.g., for an LDAP client to ensure that it is talking to the correct server).


S/MIME, which is based on X.509 technology, is used by Harrier and M-Switch to sign and encrypt messages.

The signing of messages provides:

  1. Assurance as to the originator of the message
  2. Assurance that the message has not been altered in transit

Encryption of messages provides confidentiality of the message content in transit.

These are supported for both SMTP messaging and X.400 messaging.


It is Isode's direction to provide use of PKCS#11 Hardware Security Modules as a means of storing private keys. This has been tested with Nitrokey, Yubikey, SoftHSM and Gemalto networked HSM.

HSMs can be managed using Cobalt and are currently supported in Harrier (S/MIME and TLS), M-Vault, M-Box and M-Switch.

Use of Directory

X.509 PKI can use the directory for two important functions: CRL retrieval and certificate path building. These are supported by the Isode products for Strong Authentication in the OSI protocols and for Signed Operations. Isode’s X.509 infrastructure uses LDAP to access a directory server to achieve this functionality, except in the M-Vault product where direct internal access is used.

CRL Checking

Isode’s X.509 verification can use certificate revocation checking using OCSP (Online Certificate Status Protocol) and by checking CRLs (including delta CRLs), which we can retrieve using LDAP and HTTP. M-Vault will use native retrieval when the CRLs are being stored locally.

OCSP Trusted Responder support is present for M-Vault and M-Link. Additionally, they can both be configured not to use other kinds of retrieval, meaning that it can be used in an environment requiring revocation checking and relying entirely on a local OCSP responder.

Subject Alternate Name Support

X.509 certificates use Subject Alternate Names to support name forms appropriate to different applications. Isode’s X.509 infrastructure and GUIs provide flexibly Subject Alternate Name support, and in particular supports RFC 6125 conformance for all of the Isode supported protocols.

Cryptographic Algorithms

Isode infrastructure uses the following cryptographic algorithms. Note that SHA224, SHA256, SHA384, SHA512 are not currently supported for X.500 (DAP and Signed Operations) and X.400 (Strong Authentication, MOAC and Token).

Asymmetric Cryptography Supporting Hash Algorithms
RSA MD5; SHA1; SHA224; SHA256; SHA384; SHA512
DSA SHA1; SHA224; SHA256; SHA384; SHA512
ECDSA SHA1; SHA224; SHA256; SHA384; SHA512

Strong Authentication Conformance

Isode products conform to the following standards for strong authentication, including management:

ITU-T Recommendation X.509 (1997 E) Information Technology - Open Systems Interconnection – The Directory: Authentication Framework, June 1997.
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008.
RFC 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS), March 2011.

PKCS (Public-Key Cryptography Standards) published by RSA Labs:

PKCS#10 Certification Request Syntax Standard – Version 1.7
PKCS#11 Cryptographic Token Interface - Version 3.0
PKCS#12 Personal Information Exchange Syntax Standard – Version 1.0