Focus: Encryption with S/MIME

1. How does S/MIME work?
2. What is a certificate authority (CA)?
3. What are S/MIME certificates?
4. What is the difference between a root certificate and a company certificate?
5. What do I have to check if any of the actions fails?
6. What do I have to check if encryption/verification fails?
7. What do I have to check if decryption/signing fails?
8. What are the legal framework conditions for electronic signatures?

How does S/MIME work?

When encrypting with S/MIME, two different certificates are used on both the sending and the receiving side:
  • A public certificate to encrypt outgoing mails and/or to verify incoming signed mails.
  • A private certificate to decrypt incoming mails and/or to sign outgoing mails.
S/MIME works with a strictly hierarchical trust model, based on the Root Certificate (or root CA certificate).

What is a certificate authority (CA)?

A certificate authority (CA) takes care of the following:
  • Issue certificates/certify keys
  • Maintain and publish blocking lists
When issuing a certificate, the CA links a user's name to his/her public key. The CA guarantees that the name and the public key belong to the same person. The CA ensures that any applicant for a certificate proves his/her identity to the CA.
Therefore, it is necessary that all persons involved trust the CA's public key. In case the CA's private key is compromised, all user certificates have to be reissued.
Certified public keys have to be published. Typically, an LDAP directory service is used to that end.
A certification authority can be compared to an ID card authority, with similar security requirements for the environment in which a CA is operated. For details, please refer to the PKI Basics whitepaper.

What are S/MIME certificates?

Certificates are created and managed by a certificate authority. A certificate links the data of a cryptographic key (or a pair of keys consisting of a public key and a private key) to data on the owner and a certificate authority as well as further specifications, such as version, validity period, purpose and fingerprint.
Frequently used filename extensions:
  • Files in PKCS#7 standard: .p7b (public key)
  • Files in ITU-T X.509 standard: .cer (public key)
  • Files in PKCS#12 standard: .pfx, .p12 (private and public key)

What is the difference between a root certificate and a company certificate?

Under iQ.Suite, if you want to perform server-based encryption with S/MIME, you need two certificates: The root certificate (root.pfx) is the private certificate of the root certificate authority (Root CA). It is exclusively used to sign the copies of the company certificate (company.pfx).

Generally, a Root CA is only needed to create and/or sign user certificates. A partner who trusts this Root CA also trusts all certificates and lower certificate authorities signed by the Root CA. Therefore, only one certificate needs to be trusted, once: the certificate issued by the Root CA.

To sign and/or decrypt a mail, the sender needs a certificate with his own e-mail address. In our case, the company certificate (company.pfx) serves as template, in order to create such an individual user certificate with the aid of the Root CA:
A copy of the company certificate is made and the e-mail address is exchanged and signed by the Root CA. This procedure is repeated for each user without his own certificate in the certificates database.

What do I have to check if any of the actions fails?

Check the passwords for the root.pfx and company.pfx certificates: the passwords set in the configuration must be the same as those selected when the certificates were created.
Check that the following files are located in the iqsuite\smime\data directory:

  • root.pfx
  • company.pfx
  • Check that these paths have been adjusted accordingly in the configuration.
  • Check that all certificates are valid (expiry date!)

What do I have to check if encryption/verification fails?

  • Lotus Notes/Domino:
    • Check whether you have imported a public certificate of the recipient into the certificates database (cert.nsf) and whether the certificate is accessible through an LDAP directory.
    • Check whether your own company certificate has been entered with the correct path (needed for initializing the job).
  • Microsoft Exchange/SMTP:
    • Check whether you have imported a public certificate of the recipient into the GrpData\smime\data directory. Please contact our Support for further assistance.

What do I have to check if decryption/signing fails?

  • Lotus Notes/Domino:
    • Check that your company certificate is located in the iqsuite\smime directory.
    • If you want to sign, check that the root.pfx issuer certificate is also located in the iqsuite\smime directory. The correct passwords must have been entered for both of the certificates.
  • Microsoft Exchange/SMTP:
    • Check that the private company certificate is located in the GrpData\smime\data directory.
    • In the S/MIME configuration settings, check that the paths for the certificates have been set correctly under S/MIME Options.

What are the legal framework conditions for electronic signatures?

The electronic signature is governed by several legal provisions that may vary significantly between different countries. The following legislation applies in Germany. Similar laws are in force in most of the countries in the European Union:
The German Private Law allows to replace a written signature with an electronic signature unless provided otherwise by other law (§ 126 BGB). The electronic form is complied with when the name is added to the document and the document is provided with a qualified electronic signature (§ 126a BGB). The qualified electronic signature poses higher requirements. Contract partners may also agree on some other form and in particular choose a simpler electronic signature (§ 127 BGB).
The Signature Act distinguishes between the Electronic Signature per se (therefore often called Simple Electronic Signature), the Advanced Electronic Signature and the Qualified Electronic Signature. The latter requires a valid certificate and the creation with a signature creation unit. This will normally be a chip card reader including an appropriate encryption software. The requirements imposed on chip cards with signature functionality are set out in the DIN V 66291-1 norm. The certificates are collected by the German Federal Office for IT Security (http://www.bsi.de).

The cryptographic algorithms admitted for the Qualified Electronic Signature are approved and published by the Regulierungsbehörde für Telekommunikation und Post (Regulatory Authority for Telecommunications and Posts). A list of the products approved for a Qualified Electronic Signature is also kept there. Certification services are not subject to approval but do require disclosure. This disclosure has to show that and how the legal requirements (financial cover, reliability, expertise) are met.

Summarized, the following can be said regarding server-based encryption with S/MIME and iQ.Suite:

Whoever is obliged to provide a legally binding signature, requires Qualified Certificates. These certificates are linked to natural and legal persons and have to remain in their possession at all times (e.g. on a smartcard). Only the user. i.e. no substitute (e.g. a server), is allowed to sign with theses certificates, as the certificates are password-protected.

The user-specific certificates are created by iQ.Suite Crypt at the server and are therefore not bound to a person. Using iQ.Suite Crypt, the certificates can thus be created with iQ.Suite Trust or any other program designed to generate certificates. It is not necessary to rely on the certificates of a trust center.