Relevant concepts

This page describes some basic concepts needed to properly handle X.509 certificates. In the remaining instructions on this site, we assume that all readers have read and understood this page.

Tip

The central message(s) of each section are summarized in boxes like this one.

Principal structure of X.509 certificates

X.509 certificates are part of an asymmetric cryptography system.

Asymmetric cryptography uses related pairs of related keys. Each key pair consists of a public key and a corresponding private key. The actual certificate is the public key combined with the signature of a certification authority and a set of attributes (name, validity period, purpose, serial number, …).

E-mail senders encrypt e-mails with the recipient’s public key. Recipients then decrypt them with their secret key. E-mails are signed with the secret key and validated by the recipient using the sender’s public key.

As the name suggests, the secret key must be kept secret. Anyone who possesses this key can decrypt encrypted messages and sign documents and messages on behalf of the certificate holder. This is why all procedures for generating a secret key are designed to ensure that the requesting person holds all copies the private key.

Personal certificates with and without identification

This topic is explained on a separate page.

Acquiring recipients’ certificates

As explained in the first chapter, emails are encrypted with or for their public certificate. This means that your email client must know the certificates of all potential recipients before encrypting. There are generally three ways to do this:

1. Automatic retrieval via directory services and Exchange address book
2. Receiving & reading signed emails
3. Manual import

Automatic retrieval

KIT-CA publishes all certificates in KIT’s Active Directory, which then also end up in the global address book of Exchange. Microsoft Outlook is the only client that can reliably obtain certificates automatically from there.

Reading signed emails

All email clients covered in this guide (Outlook, Thunderbird, Apple Mail) import the certificates of signed emails when they are read. For this reason, we also recommend always signing emails in our instructions.

Manual import

If the other two methods are not an option, you can also import other people’s certificates manually. This method is rather time-consuming, impractical and does not scale well, which is why it is only documented here as a final option.

Certificates from the KIT-CA can be searched for and downloaded via our CA search. These can then be opened and integrated into the system under Windows and macOS by double-clicking the downloaded certificate file.

In Thunderbird, the import is performed via ☰ → Settings → Manage Certificates → Tab People → Import….

Backups

Because the private keys are only held by the certificate owner, they must themselves create secure backups of all private keys. These backups must be accessible for as long as anyone still wants to decrypt/read the corresponding encrypted e-mails. This means that every certificate holders needs backups of all certificates/private keys until they leave KIT. Make sure that you will also be able to know/retrieve the passwords of the .p12 files many years from now.

Backups

Make secure backups/copies of the private keys of all certificates until the end of your employment relationship with KIT. The private keys are normally contained in files with the extension .p12 or .pfx. Also remember to back up all associated passwords.

Always sign e-mails

To encrypt e-mails, the sender needs the certificates of all recipients in advance. Users of Outlook at KIT receive these via the GAL (“Global Address List”). Users of other e-mail clients save these automatically from signed e-mails.

Always sign e-mails

Always sign your e-mails. This helps to distribute your certificate to all potential correspondence partners.

Only one certificate per identity/entity

Function and group certificates

If you share an e-mail address with several people, all the people concerned must share a single certificate. The person requesting the certificate must therefore distribute it to the rest in a secure manner.

When sending encrypted messages, the sender’s e-mail client selects exactly one certificate for each recipient. If the e-mail client knows of several valid certificates, some (often undocumented) rules are used to select one; usually either the newest or the one with the longest validity. Therefore, there should only ever be one valid certificate per identity.

Always revoke lost certificates

If you no longer have access to the corresponding secret key for a certificate, revoke it immediately. This will prevent reception of emails that cannot be decrypted.

See here for a guide on how to revoke certificates.

If you want to sign or decrypt e-mails on more than one device, you must securely transfer your private key and the certificate (in practice: the .p12 file) to all devices in a secure way and set them up there.

Distribute certificate to all end devices

Copy your current certificate to all relevant end devices.