A digital certificate is part of a cryptographically secured procedure with the help of which the owner of the certificate can identify himself. Certificates can be used, for example, to sign e-mails or log in to portals - provided the e-mail programme or portal supports certificates.

The certificates we create consist of a public and a private part. The public key allows anyone to encrypt data for the holder of the private key, to verify their digital signatures or to authenticate them. The private key enables its holder to generate digital signatures, authenticate himself or decrypt data encrypted for him. As a rule, the public key is published after its creation - e.g. on a key server.

Since, in principle, anyone can generate key pairs with almost any content, another component is needed to finally ensure the identity of the key owner. For this purpose, the user's public key is signed by a certificate authority (CA). Before the signature, the associated Registration Authority (RA) checks the identity of the user, for example on the basis of the identity card. The CA's signature can be verified in the same way using the CA's public key. The authenticity of the CA itself is again ensured by a signature of the next higher certification authority. This continues until one has reached the top root certificate. If one now trusts the provider of the root certificate and the certificate chain, then one can uniquely identify a user. The certificate chain created in this way is also called a "chain of trust".

Protection of private keys

If someone now comes into possession of your private key, they can write mails in your name or log into your account on portals and servers. It is therefore crucial that you protect the private part of your key as well as possible.

Firstly, you should use a good password for your keystore. The keystore is the place where your key is stored locally. Without the password, no one can take the private key from the keystore.

Secondly, you should only store your private key in secure locations - e.g. on a USB stick only accessible to you or, even better, on a crypto stick. Publicly accessible home directories, e.g. Unix NFS or Windows Active Directory servers, are NOT a good place to store the certificate. Unfortunately, however, in practice it is sometimes unavoidable to store the private key in a less secure location. For example, if you use our pool computers and the Firefox keystore there, the keys automatically end up in the NFS home directory (Linux pools) or on the Active Directory server (Windows pools). It is then all the more important that you secure the keystore with a reasonable password.

If, despite all precautions, your certificate is compromised, you can recall your certificate. This usually happens where you also applied for the certificate. The certificates deactivated in this way are announced in so-called "Certificate Revocation Lists" (CRLs) by the certification authorities. All properly configured systems (e-mail programs, portal servers, login servers) take the entries of the CRLs into account when checking certificates.

If you lose your private key or if you forget your keystore password, this will inevitably lead to the loss of all files and e-mails encrypted with your public certificate. You should therefore create a backup of your private and public key (preferably in pkcs12 format with the extension .p12) as soon as you have imported the signed part of your key.

DFN Global and Grid Certificates

Our certification authority only issues certificates of the type "Global" on behalf of the DFN Association (German Research Network). Certificates of the type "Grid" cannot be applied for at present.

Please note that electronic signatures using the certificates we create are not legally binding.

The global certificates are usually valid for 3 years (Generation 1 certificates until July 2019 at the most) and are used, for example, to sign e-mails. A decisive advantage of DFN global certificates is that the root certificate of their key chain is already included in most browsers and email programs. Therefore, the verification of the sender identity usually works automatically. The key chain of the DFN Global certificates of generation 1 (until July 2019) originates from the "root certificate Deutsche Telekom Root CA 2". The key chain of the DFN Global certificates of generation 2 (from July 2019) originates from the "root certificate T-Telesec Global Root Class 2".