What does the 10th certificate number of the class mean?

Questions and answers about certificates in the DFN-PKI

Each certificate holder must ensure that his private key is adequately protected and that the certificate is used in accordance with the DFN-PKI policy. The certificate must be revoked immediately if the information on the certificate is no longer correct or if the private key has been lost, stolen or possibly compromised. A description of these obligations can be found in the document "Information for certificate holders in the DFN-PKI".

The certificate name must not contain umlauts or other special characters. A-z A-Z 0-9 '(), - are allowed. /: and spaces. Pay attention to upper and lower case letters. This applies to all components (attributes) of the certificate name.

The certificate name must correspond to the name form specified in the CPS of your certification authority. Particular attention must be paid to the attributes that are permitted or specified there. When applying for a user certificate via the web interface of the certification authority, the specified attributes are automatically adopted. Rules for the "Common Name" (CN attribute) in the certificate name can be found under question 3.

When applying for a server certificate, the certificate name must be transmitted in a PKCS # 10 certificate request. Information on generating a PKCS # 10 certificate request with the correct certificate name can be found in the instructions for using OpenSSL.

In addition to the general rules for certificate names (see question 1), the following must be observed for the CN entry:

User certificates:
The CN of a user certificate must contain first and last names. Exceptions are group certificates (CN = GRP: ... or GRP - ...) and pseudonym certificates (CN = PN: ... or PN - ...). Name additions that are used in the official identification document (e.g. "Dr.") can be included in the CN. Name additions not listed therein (e.g. "Prof.") may not be used in the CN.

Server / machine certificates:
The CN of a server certificate must always contain the fully qualified host name (FQDN), e.g. server1.uni-musterstadt.de. The second-level domain (in the example uni-musterstadt) must be officially registered with a domain registry (e.g. DENIC) and the FQDN must be below a domain activated by the domain validation.

IP addresses must not be specified in the CN.

If, for certain reasons, an unregistered or not fully qualified host name has to be used, this can be entered as the Subject Alternative Name (SaN) in the certificate extension "subjectAlternativeName" with the type "DNS". IP addresses can also be entered as "subjectAlternativeName" with the type "IP". Please note that newer versions of Internet Explorer do not accept IP addresses in the Subject Alternative Name.

As a rule, SaNs can only be entered by the registration authority by processing an existing certificate application. If the free fields provided for SaNs in the processing mask of the RA web interface are not sufficient, the application must be saved after filling in the available fields and processing must then be continued. Additional free fields are then displayed for further SaNs.

When using an alternative name, the fully qualified host name from the CN should also always be specified as a further "subjectAlternativeName". This helps many browsers / clients to avoid warning messages about server names that do not match the certificate.

The entry of a "subjectAlternativeName" in a PKCS # 10 certificate request, which is transmitted to users and administrators via the web interface, is generally adopted in the DFN-PKI. Exception: The facility has explicitly agreed to ignore the "subjectAlternativeName" for its CA.

In the global security level, internal domain names such as "mail.local" or reserved IP addresses such as 192.168.6.1 may no longer be used in certificates since autumn 2015.

A detailed description and further information on this problem can be found in the document "Internal names in server certificates in the DFN-PKI."

If you apply for a certificate via the web interface of your certification authority under the "Server Certificate" tab, you must select a certificate profile that matches the purpose of this certificate. Which certificate profile is suitable for which purposes can be found in the list DFN-PKI certificate profiles (technical description of the profiles).

To apply for a server certificate via the web interface of your certification authority, the certificate data must be transmitted in a PKCS # 10 file in .pem format. To do this, enter the name of the file in the appropriate place in the web interface.

The file can be generated in various ways, e.g. with the help of the appropriate server software. Please read the documentation for your server software and follow the instructions.

A PKCS # 10 file can also be created using the open source software OpenSSL (http://www.openssl.org). Please read the instructions for using OpenSSL.

A CSR for a certificate in the DFN-PKI must meet the following conditions:

  • It belongs to an RSA key with a length of at least 2048 bits, which is available e.g. as a file or within the application and is possibly protected with a password.
  • It is self-signed by the key it contains.
  • The certificate name (Distinguished Name, DN) requested in the CSR complies with the rules for certificate names (see question 1) and corresponds to the name form specified in your CPS. Particular attention must be paid to the attributes that are permitted or specified there. To do this, please read Chapter 4 "Certificate names" in the instructions for using OpenSSL.

To generate a PKCS # 10 certificate request, please read the instructions for using OpenSSL.

If you want to check the file with your PKCS # 10 certificate application before uploading it to the web interface, you can use OpenSSL to do so. With the command line

openssl req -text -verify -in request.pem

OpenSSL shows you the content of the CSR file "request.pem" in readable form and also verifies the self-signature of the CSR.

If necessary, also read the instructions for using OpenSSL.

If you have the PKCS # 10 certificate request as a file, you can calculate the public key fingerprint with openssl by using the following command line under Linux or Cygwin.

For openssl 1.0 and 1.1.0:

openssl req -in -pubkey -noout | openssl rsa -pubin -text -noout | sed -e '/ modulus: $ / d' | sed -e 's / Public-Key: (\ (. * \)) / Modulus (\ 1): /' | openssl sha1

For openssl 1.1.1:

openssl req -in -pubkey -noout | openssl rsa -pubin -text -noout | sed -e '/ modulus: $ / d' | sed -e 's / RSA Public-Key: (\ (. * \)) / Modulus (\ 1): /' | openssl sha1

To import a certificate into an application, you usually need the certificate together with the private and public key and, if necessary, with the entire certificate chain in a PKCS # 12 file (extension .p12). When you have generated the key pair in your browser and imported the certificate into the browser, you can export a PKCS # 12 file from the browser. See FAQ-Mozilla, question 5 or FAQ-Windows, question 4.

If your private key and certificate are stored elsewhere on your computer (usually for server certificates), you can use OpenSSL to create a PKCS # 12 file that contains the certificate, the private and public key and the CA Contains certificate chain.
Please read the instructions for using OpenSSL.

Since certificates have an expiry date, they have to be renewed or extended regularly. A certificate renewal is the issue of a new certificate with the same distinguished name as an existing certificate. The new and old certificates always differ at least in terms of the validity period and the serial number.

Technically, the certificate renewal can be carried out in two ways: Either by exchanging the secret and public key or while retaining the old key pair.

Basically, the first way with exchange should be chosen, which corresponds to a new exhibition. The old key pair must be kept in any case, otherwise encrypted data such as e-mails can no longer be read. Certificates for web servers, which were never used for persistent encryption of data, are an exception. A certificate renewal can also be carried out here without any problems without exchanging a key.

The certificate renewal without key exchange has advantages in theory, but is problematic in practice: Most software identifies keys on the basis of the associated certificate, so that an inadvertent deletion of expired certificates can lead to encrypted data no longer being accessible.

For an extension, proceed in the DFN-PKI as with the initial application. The applicant calls up the application pages of his certification authority, creates an application while retaining his information from the old certificate and prints out this application. The application must then be sent to the registration office, which will take on further processing.

When publishing certificates, a fundamental distinction must be made between user and server certificates.

The following applies to user certificates:

If you agree to the publication of your user certificate, it will be added to the directory service of the DFN-PKI, which is freely accessible on the Internet. The advantage of publishing is that anyone who wants to send you an encrypted email can easily do so, as the relevant certificate is freely available. Since user certificates contain the name and e-mail address of the subscriber, these data are freely available if they are approved for publication.

The publication of a user certificate is comparable to a telephone number that you can have entered in a public telephone directory. If you agree to the entry, anyone (whether desired or not) can contact you by phone without prior contact.

Please note:

  • You can revoke your consent to the publication of your certificate at any time with effect for the future by sending an email to [email protected] In the email, please tell us the serial number of the certificate and the issuing certification body. This information can be found in the certificate details.
  • If you do not agree to the publication of your user certificate, this cannot be changed afterwards. You then have to apply for a new certificate and agree to its publication.

The following applies to server certificates:

Server certificates are published in the DFN-PKI in Certificate Transparency Logs. These are systems operated by third parties that serve the transparency and thus the security of the Web-PKI. Without the publication, server certificates would no longer work in Google Chrome.

The publication of server certificates can Not be withdrawn. Certificate Transparency Logs are operated by third parties over which the DFN has no influence. In addition, Certificate Transparency is based on data structures that are inherently secured against subsequent changes by digital signatures.

Further explanations can be found in the blog of the DFN-PKI.

The directory service of the DFN-PKI for user certificates with the global security level is implemented by the following LDAP server:

  • Hostname: ldap.pca.dfn.de
  • Ports:
    • 636 with TLS / SSL (preferred)
    • 389 with and without STARTTLS

You can find the user certificates released by the owner for publication in the global security level at:

  • Base DN: ou = DFN-PKI, o = DFN-Verein, c = de

For user certificates in the grid security level, use instead:

  • Base DN: o = GridGermany, c = de

If you access a certificate-protected website with a browser, you will receive an indication of the security level under which the corresponding certificate was issued. "Extended Validation (EV)" certificates contain a reference to the certification guideline of the issuer and can therefore be specifically displayed by browsers if this certification guideline is subject to a "stricter" check (e.g. the URL bar is colored green and the name of the appears Exhibitor in green).

"Extended Validation" certificates cannot be issued in the DFN-PKI Global at the moment.

In addition to the X.509 certificates established as the standard in the DFN, there are alternative PGP certificates. There is, among other things, a significant difference between the two structures: If trust is built in X.509 via a hierarchical system of certification and registration authorities, in PGP this is done via a so-called "Web of Trust".

In the DFN-PKI, only X.509 certificates are issued due to the requirements of the DFN users. Every user is free to generate his own PGP key pair and obtain certificates via the Web of Trust.

You can get the fingerprint of a root certificate using the OpenSSL command

 

openssl x509 -in -noout -fingerprint

 

output. Compare the fingerprint with the fingerprint published by the CA. These must be the same. You should obtain the fingerprint published by the CA in a different way than the root certificate - for example by telephone.

Wildcard certificates are special server certificates in which the FQDN in the CN or in an alternative name of the 'DNS' type on the leftmost domain component contains an asterisk ("*") - the wildcard.

Example: CN = *. Pki.dfn.de

This means that this certificate can be used for all FQDNs below pki.dfn.de, e.g. for pki1.pki.dfn.de and pki2.pki.dfn.de, however Not for longer FQDNs such as www.pki1.pki.dfn.de or shorter ones such as pki.dfn.de itself.

Since wildcard certificates can be used for an entire subdomain, the potential damage if the private key is compromised is significantly higher than with certificates for precisely specified FQDNs.

For this reason, wildcard certificates should only be used in the DFN-PKI if the application scenario requires it from a technical point of view. For example, there are software systems that dynamically generate host names (especially in the library environment) that simply do not work with conventional certificates. Examples of such software: EZProxy, Netman / HAN

The same wildcard certificate should not be used on different servers with different services, purposes or protection classes. Due to the higher potential for damage if they are compromised, wildcard certificates are not an effective means of saving work when applying for a certificate.

Wildcard certificates should therefore only be issued below sub-domains or second-level domains that are only used for a clearly defined purpose, for example either for "* .roaming.dfn.de" or for "* .dfnroaming. de ", but not for" * .dfn.de "

Logs from the operators Comodo, Cloudflare, Digicert and Google are used. As of March 30, 2020, certificates are potentially written in the following logs:

mammoth.ct.comodo.com
sabre.ct.comodo.com
ct.cloudflare.com/logs/nimbus2020
ct.cloudflare.com/logs/nimbus2021
ct.cloudflare.com/logs/nimbus2022
ct.cloudflare.com/logs/nimbus2023
nessie2021.ct.digicert.com/log
nessie2022.ct.digicert.com/log
nessie2023.ct.digicert.com/log
yeti2021.ct.digicert.com/log
yeti2022.ct.digicert.com/log
yeti2023.ct.digicert.com/log
ct.googleapis.com/logs/argon2020
ct.googleapis.com/logs/argon2021
ct.googleapis.com/logs/argon2022
ct.googleapis.com/logs/argon2023
ct.googleapis.com/logs/xenon2021
ct.googleapis.com/logs/xenon2022
ct.googleapis.com/logs/xenon2023

updated on: 05/11/2021 |