Relevant concepts

This page describes some basic concepts needed to properly handle X509 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 X509 certificates

X509 certificates are part of a 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.

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

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. Then you will not receive any emails that cannot be decrypted.

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.