July 2013


Isode’s applications make extensive use of digital signatures and strong authentication, providing significant security and administration benefits. PKI (Public Key Infrastructure) has a reputation for being complex and difficult to deploy. While certain aspects of PKI are complex, Isode's approach has been to make management and deployment of these capabilities be as straightforward as possible.

This paper looks at some of the issues that arise when deploying applications that use PKI, and how Isode's management toolset helps address these issues. There are three key points which the paper focuses on:

  1. Use of PKI provides significant security and administrative benefits.
  2. If you are using Isode applications, it is straightforward and valuable to use PKI.
  3. When comparing Isode server software to alternatives, the Isode approach to PKI management provides clear advantages.
Creative Commons License

Digital Signatures, Encryption and PKI

Digital Signatures are an important part of modern secure infrastructure. They use Asymmetric Cryptography, which means that the signer uses a "private key" that does not need to be shared in the manner required by password based applications. This is desirable, as sharing keys leads to a number of security risks that can be avoided by use of private keys. It also enables smart card use, with private key stored on the smart card. Finally, it facilitates multiple entities verifying a signature, which impractical with shared key approaches.

There are two basic uses of digital signatures:

  1. Signing an object or block of data. For example, S/MIME message signing and directory signed operations.
  2. Peer authentication, where digital signatures are used to identity a peer connecting over protocol. This is often referred to as "Strong Authentication".

Data encryption is often facilitated by asymmetric cryptography, using technologies such as S/MIME and TLS. The basic approach is to use asymmetric cryptography such that only the holder of the private key can decrypt the data. This enables anyone with access to a user’s public key to encrypt data for that user in a way that only that user (the private key holder) can read it.

There are three types of strong authentication:

  1. Server Authentication. This is where a server identifies itself with a digital signature for the client to check. This is very widely used with HTTPS that enables clients to verify secure web sites.
  2. Server to Server authentication. This is where a pair of servers mutually authenticate with digital signatures. This has strong security and administrative upside, and Isode recommends that this should always be used where secure server to server communication is needed.
  3. Client authentication. This is where a server uses strong authentication to verify a client. This is almost always used in conjunction with (strong) server authentication, provides good security, and is recommended for administrator authentication and in highly secure environments. For clients, strong authentication deployment has some operational downsides relative to password based authentication.

This is discussed in more detail in the whitepaper [Why Strong Authentication? – The Security and Administrative Benefits of using X.509 PKI based Strong Authentication].

A digital signature created by a private key gets verified by the associated public key. An entity verifying a digital signature needs to make the cryptographic check and it also needs to be certain that the public key actually belongs to the entity that purported to make the digital signature. PKI (Public Key Infrastructure) addresses this question.

Certification Authorities (CAs) issue Certificates, that verify the association of a public key with an entity (using one or more Subject Names). Certificates are signed with a digital signature. CAs can also issue certificates for other CAs.

An entity verifying a digital signature needs to trust a CA, referred to as a "trust anchor". The entity will hold a copy of the CA’s self-signed Certificate, which holds the public key of that CA. In the simple case, the trust anchor CA will have signed the certificate being verified, and so there is direct trust. In the more complex case, there will be a trust chain via one or more CAs. This approach gives flexibility and scalability, but does lead to complexity. Further information is given in the whitepaper [A Short Tutorial on Distributed PKI].

Isode Application use of Digital Signatures and Encryption

Digital signatures are used widely across the Isode product set:

  • Directory products use digital signatures for client/server authentication, server/server authentication and signed operations.
  • X.400 Messaging products use digital signatures for Server to Server authentication, Message Signatures (X.400 & STANAG 4406) and STANAG 4406 message encryption.
  • Internet Messaging uses digital signatures for client/server authentication (POP, IMAP, SMTP, SOM), server/server authentication (SMTP) and message signatures & encryption (S/MIME).
  • XMPP Instant Messaging products use digital signatures for client/server XMPP authentication, server/server XMPP authentication and HTTPS server authentication in BOSH.
  • Our Security Label Server: uses digital signatures for client and server HTTPS authentication.

Standard CAs and Application Deployment on the Internet

X.509 PKI is widely deployed on the Internet and extensively used in support of HTTPS (HTTP over TLS) Web authentication. When you connect to a Web site with HTTPS, the client will authenticate the connection using the server’s certificate. For example, if I connect using HTTPS to Microsoft, the certificate shown below is verified (shown here with its trust path back to a trust anchor, Baltimore CyberTrust Root).

Certififcate Verification
Certificate Trust Path

Desktop machines will usually be installed with a set of trust anchors configured by the operating system vendor. The following screenshot shows the trust anchor list from a Windows 8 PC running at Isode.

This list shows some of the trust anchors configured, with the one used by the certifcate above highlighted. You can also see that Isode's own CA has been added to the trust anchor list for this PC. This is unusual, as most PCs will only have the list installed by the operating system vendor. The key point is that the trust anchors are configured on the computer, and most users just accept what the operating system vendor provides.

The dominant use of this infrasctructure is for Web server authentication using HTTPS. Web sites can purhase certifcates from a CA that is in the "standard list", and clients can then trust them. Public CAs need to demonstrate that they perform appropriate checks when issuing certs, in order to be configured as "trusted" by the operating system vendors.
Other common uses of this infrastructure:

  • Code signing, to help end users verify the authenticity of downloaded code.
  • IP level security, for example to support a VPN.
  • Client certificates, in paricular for:
    • HTTP client authentication.
    • Secure email using S/MIME.

Use of client certificates is relatively uncommon. The vast majority of usage is for HTTPS Web Server authentication.

Application Naming and Certificates

When the primary verifier of a certificate is a human (e.g., when looking at the organization that signed a software package), the most important parts of a certificate are the human readable ones (e.g., Organization Name, Address) that the human making a trust decision can validate.

When protocol is used, a key check is to match the identity used in protocol to the certificate. For example, in the www.microsoft.com Web access example of the previous section, the certificate contains the domain name www.microsoft.com, which is verified to match the domain connected to. It can be seen that this name matching is a critical part of the security check, because without it, any valid certificate could be used, rather than one which is specifically verifying the web service in question.

The rules vary for different protocols, and have been standardized for servers in 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)". Technically this specification defines how "Subject Alternate Names", which enable multiple name forms within certificates, are defined. This relatively recent standard is not yet widely adopted.

Widely deployed PKI works well for Web services, and for some other services. Shortcomings can be seen by considering Isode’s primary applications:

Internet Messaging

  • Client side is well handled by S/MIME certificates, which are widely available.
  • Server side can be handled by domain based certs (Web certs). This is not ideal, as for many deployments it would be preferable to use RFC 6125 SRV-ID certificates so that specific services could be individually authenticated. This may well become generally available as RFC 6125 sees increased adoption.


  • XMPP server side requires SRV-ID certificates. Only one public CA (Startcom) is known to be able to issue such certificates, and is recommended for XMPP server deployment on the Internet.
  • XMPP client side needs certificates with JIDs (the end point identification for XMPP users). These are not generally available in certificates. One option is to use S/MIME certificates, which is viable where JID and email address are the same.

X.400 & STANAG 4406 Messaging

  • X.400 defines a set of Subject Alternate Names, for use with PKI. These are not generally available in CA products and services.

LDAP and X.500 Directory

X.500 and LDAP (which is based on X.500) name peer entities with Distinguished Names. These are used as the Subject Name of an X.509 certificate, reflecting the common technical history of X.500 and X.509 PKI. While it should be technically straightforward to provide certificates for LDAP and X.500 services, most CA products and services constrain the names that are available, making it impossible to issue certificates that match the names of clients and servers.

Isode addresses these issues in a number of ways:

  1. For the Isode applications, our management tools will issue CSRs (Certificate Signing Requests) for "correct" certificates, to facilitate deployments to use certificates that enable end entity validation for the protocol in question.
  2. We provide the Sodium CA product, which can issue "correct" certificates for all of our applications. This enables secure deployment of all of our applications.
  3. Where customers choose to use the best certificates that they have available, Isode products are flexible to use certificates that do not follow the application rules, and to make the best pragmatic checks that are possible with the certificates that are chosen.

Military and Government PKI

Government, military and private organizations deploy PKI in a very different way to the open Internet. It would be laughable for such organizations to rely on Microsoft and Apple to determine who can be trusted. The key aspects of a military or government PKI are shown below.

An organization will start with a "top level" CA for the organization. This CA will typically not issue end user certificates, but will simply register a number of subordinate CAs. For large organizations, there will be multiple levels of subordinate CA. This hierarchy has two purposes:

  1. It delegates control, which is a natural approach to management and scaling.
  2. Having the top level CA compromised (e.g., third party access to the private key) is particularly problematic. By having the top level CA only issue a very limited number of certificates (to a few subordinate CAs), it is much easier to give a very high level of protection to the Organizational CA’s private key (e.g., by keeping the CA offline and locking the private key in a safe). The top level CA certificate will typically be given a very long lifetime (tens of years), whereas subordinate CA certificate lifetimes may be shorter.

Users of this type of PKI will generally be given a single trust anchor, which gets configured as part of the deployment. The organizational CA will often be used as the trust anchor. Another approach is to use a special CA for the trust anchor. Because the CA is likely to only need to generate one certificate (for the organizational CA) then it will make protection of the private key easier. It will be seen later, that PKI provides useful mechanisms to deal with key compromise. However, the trust anchor is likely to be configured on large numbers of machines, and so dealing with trust anchor compromise would be operationally exceedingly hard. So it is important to ensure that trust anchors (i.e., the private key associated with the trust anchor) are not compromised.

Trust for other organizations is managed as a part of the PKI, using cross-certification. The diagram above shows cross certification with a peer organization. The cross-certification allows quite a bit of control on the trust that is conferred. In order to avoid the complexity of every organization cross certifying with every other organization, multiple levels of cross certification will often be seen. In particular a bridged architecture may be used, where a Bridge CA cross certifies with many organizations.

Isode’s PKI approach aims to deal with both Internet deployments and this type of Military/Government PKI deployment. Issues that must be considered:

  • Trust anchor management. Applications need to be configured to use the right trust anchors.
  • Path Discovery. For internet style use, the trust anchor will be held locally, and the application will provide all intermediate certificates. This means that the application simply needs to verify the certificates provided. Where there is cross certification, the entity verifying the certificates will need to do "path discovery" in order to obtain all of the certificates needed.
  • Certificate validity checking. X.509 provides a range of options for checking certificate validity. These are typically turned off for Internet deployments, but are vital for government and military.

These are differentiating features of the Isode product set.

Key Problems for Isode to Address

The title of the paper promised "Easy PKI" and the paper so far has described complexity and problems. In order to make PKI straightforward to deploy, Isode does a number of things.

  1. PKI provision independence. It is anticipated that Isode customers will typically have an existing PKI and will wish to use it. To address this, Isode:
    • Provides PKI related configuration in the management GUIs, but ties this to the PKI provision (CAs) using CSRs (Certificate Signing Requests) so that the application management can interact with any CA.
    • Provides PKI visualization from the Isode management tools, to help analyze PKI configuration, particularly those arising in military and government deployments.
    • Recognize that many existing CAs cannot generate "correct" certificates for the Isode applications, and so provide options to deal in the best possible manner with the certificates that can be provided.
  2. Enable advanced PKI features, necessary for government and military deployments:
    • Provision of flexible path discovery from military and government deployments, both with and without directory.
    • Enable flexible certificate validation, using HTTP, LDAP and OCSP.
  3. Straightforward deployment for customers who do not have an existing PKI.
    • Isode provides Sodium CA, which gives a straightforward PKI that integrates easily with the Isode applications and supports all of the recommended certificate formats.

CSRs & Key Pair Generation

When configuring applications, Isode management tools offer the option to create identities for use with X.509 PKI. The following example is from M-Vault Console, the management tool for the M-Vault directory server.

Here the "Create" option will lead to the creation of a Certificate Signing Request (CSR) which can be sent to the CA of choice. What goes on behind the scenes:

  1. A public/private key pair is created (for the chosen algorithm and key strength). The private key is stored securely, minimizing risk of exposing the private key.
  2. The private key is used to sign the CSR, which contains:
    • The public key, which will be in the certificate.
    • Requested certificate parameters.
  3. The CSR is then passed to the CA of choice, which will generate a certificate that is provided back to the requestor.
  4. The certificate and private key are then combined to be held as the complete identity, which is then installed in the correct place. If the certificate is for an end user, the identity may be provided as a PKCS#12 format file (encrypted), to be sent to the end user.

The UI in front of this is a simple wizard. The user can type "next" to each screen and get a reasonable set of defaults. A key screen, which controls setup of the name choices for the certificate is shown below.

The SubjectName (shown in the title bar) is the Distinguished Name of the directory server. A number of Subject Alternate Names are also offered:

  1. The DNS name of the machine. This is selected by default, and generally useful for LDAP, where the DNS name of a server should be validated by the LDAP client.
  2. IPv4 and IPv6 addresses are also offered. In a secure environment, it may be considered desirable to have the client or peer verify the IP address of a server, and these options make this straightforward to set up.

The wizards are designed to be easy for the novice, but to give appropriate configuration choice to the expert.

A key step in the wizard is the interaction with the CA. The Isode wizards give several choices here, to facilitate interaction with CAs that have different requirements for CSRs. This is the middle step of a straightforward identity creation process, which is essentially:

  1. Start Wizard to create identity.
  2. Interact with CA.
  3. Finish wizard which creates identity.

At the end of the process, the certificate associated with the identity is shown, prior to configuration of the identity for the application

The installed certificate is then shown, and can be viewed from the management tool:

This process is available in three Isode management tools:

  • M-Vault Console, as show above, for creating M-Vault Server identities.
  • M-Link Console, for creating M-Link Server identities.
  • Sodium for creating user identities, which can be for local users, or for remote users by use of a PKCS#12 transfer file.
  • Sodium is also currently used for M-Switch configuration. Medium term we plan to add support in MConsole.

PKI with and without Directory

The original X.509 PKI design had a very close relationship with X.500 directory, and use of LDAP and X.500 directory to support PKI is a sound and common approach. Capabilities provided by the directory are:

  • End user lookup and Certificates. This is particularly important to support encryption.
  • CRL (Certificate Revocation List) storage as part of the certificate validation process.
  • Path discovery, to find a trust path between a trust anchor and a certificate being validated.

This directory approach works very well and is described in the white paper [Distributed Directory in support of large scale PKI].

X.509 has evolved, so that it no longer requires a directory that covers the entire PKI. In particular, CRL location can be explicitly referenced, either over HTTP or over LDAP (in a server that can be disconnected from other parts of the PKI). Similarly, information needed for path discovery can be referenced from the certificate.

Isode’s applications use PKI in a generic way, and will provide full functionality to either type of PKI setup or a hybrid configuration.

Trust Anchors

Trust anchors are a vital part of PKI support. Isode clients and servers offer two basic approaches to trust anchor configuration.

  1. On Windows, the trust anchors configured in the Windows Certificate Store may be used. This enables trust anchors to be configured system wide, and simply have them referenced by the Isode applications.
  2. Explicit configuration of the trust anchors for the Isode application

The following screenshot shows a trust anchor configured for M-Vault shown in M-Vault Console, reflecting the common setup where a single trust anchor is used. Additional trust anchors can be easily added.

Dealing with Real CAs

A problem noted earlier is that many deployed CAs do not support the application naming conventions required by some Isode applications. This has been a particular issue with XMPP, which has clear requirements on both client and server certificate formats.

This gives operational issues when customers wish to deploy using CAs that do not meet these requirements. The approach to address this is a series of options in M-Link, shown below in the M-Link Console GUI, which enable the manager to specify how matching of SAN (Subject Alternate Name) and Subject should be treated when matching client and peer server certificates. This enables deployment with CAs that issue certificates not aligned to the application standards, and maximizes the useful verification that can be achieved from these certificates.

Sodium CA

Isode include a Certification Authority, Sodium CA, in its product set as a part of the application management suite.

One reason for using Sodium CA is simply as a demonstration and evaluation tool for the PKI capabilities of Isode applications. Benefits of using Sodium CA for this:

  • Very easy to set up.
  • Easy to set up a configuration with multiple CAs with hierarchy and cross-certification.
  • Natural integration with the Isode applications.

Sodium CA is also intended for operational deployment. Reasons it may be chosen (in addition to the reasons noted for demonstrations):

  • Where only a small number of certificates are needed to deploy Isode applications, this is a much easier path than procurement and deployment of an independent CA.
  • Sodium CA can issue “correct” certificates for all of the Isode applications, which leads to security benefits. Sodium CA may be used for such certificates, and then cross-certified into a broader PKI.

Sodium CA is designed to be used with an LDAP/X.500 directory, and will publish information in the directory. It can also be used standalone.

The primary view of Sodium CA shows issued (and revoked) certificates, with capability to revoke, renew and rekey issued certificates. Incoming certificate requests (CSRs) are handled by issuing certificates, making it easy to issue certificates as requested or to modify to what is appropriate.

Sodium CA can connect to and browse the directory. This helps update and verify information in the directory and also enables direct issue and publishing of certificates.

Certificate Validity Checking

An important capability of PKI is that certificates can be revoked. Certificate validity checking is usually mandatory for government and military deployments. Many PKI implementations have limited CRL checking options.

The "classic" approach is that a Certificate Revocation List (CRL) is issued at intervals by the CA and published in the CA’s directory entry. This basic mechanism has been extended in a number of ways, including:

  • Use of Delta CRLs, to optimize performance issues caused by large CRLs.
  • Use of CRL Distribution Points, which enables CRLs to be published in HTTP or explicitly referenced LDAP servers or at a generic directory location.

An alternative approach to looking at CRLs is the OCSP (Online Certificate Status Protocol) which is a protocol to check if a certificate is valid.
This can help to ensure accuracy of the validity checking and can sometimes improve performance.

Isode provides a range of certificate validity checks in its applications:

  • Configuration to access directory to use “classic” checking.
  • Use of information in Certificates to use LDAP and HTTP CRL Distribution Points and OCSP.
  • Check all certificates in the path, or leaf entry only.
  • Control over which mechanisms to use or prefer, which can be important to optimize performance when multiple mechanisms are available.
  • Force use of OCSP checking against a configured OCSP server (Trusted Responder).

PKI Visualization & Verification

Many products with PKI capabilities perform configuration using command line tools. This approach is workable for an Internet Web service, but for more complex PKI configurations that are typical in military and government deployments, it makes configuration tricky and analysis and debug of error situations extremely hard.

Isode provides GUI tools for setup of PKI, which have been extensively illustrated in the previous sections. We also provide tools to visualize and verify PKI information, which is crucial to help analyze complex PKI configurations.

The following set of screenshots are taken from Sodium, Isode's directory client that accesses data and PKI information in the directory. This entry shows a CA, including the CA's own certificate and its current CRL (Certificate Revocation List). It also shows a cross certificate pair with a second CA. The full green ball indicates that both halves of the cross certificate pair are present, consistent and valid. Cross certificates are key to a complex bridged PKI.

This next screenshot shows a user entry, with a certifcate that includes and email address (suitable for S/MIME) and a JID for XMPP. Sodium is bound to the directory using strong authentication. Details of the certificate can be viewed, and the certificate can be verified.

Next we see the results of the verifcation. A simple trust path to the trust anchor is shown and the result includes CRL checking with the CRL taken from the directory. The CRL used is shown. This detail of analysis is important when seeking to analyse failures.

As well as Sodium, there is visualization and verification support in appropriate parts of the Isode application management tools. These final screenshots are taken from M-Vault Console relating to configuration of strong authentication between a pair of DSAs for replication. This screenshot shows the certificates for each of the DSAs in the replication agreement, and records that verification was successful.

The verify button shows that verification in each direction works. There needs to be verification in both directions, as the link has two way trust.

Finally we see the results of the verification. Note the more complex trust path than in the earlier example. Here, the trust chain goes between the pair of bridged CAs.


This paper has looked at the benefits of using PKI and strong authentication, and looked at some of the key issues associated with making deployments, particularly in military and government environments. The paper has shown how Isode’s GUI tools help to hide the complexity, and make setup and management of this sort of deployment straightforward.

Easy PKI is a significant claim, and we encourage the skeptical to evaluate our products and try out the capabilities. Isode will shorlty be publiushing and evaluation guide to aid with this.