Language:

Personal Certificates

Do you have questions about our personal certificates? We will be pleased to assist you. You can find information in our FAQs section or you can contact our support team directly. 

General Information

The baseline requirements are specifications intended to ensure that a security standard defined there for issuing trustworthy certificates is adhered to.

As the operator, I must make sure that domain validation has been successfully completed before certificate production.

No, you can use them without restriction until the regular end date.

No, certificates that have already been issued retain their validity and do not have to be blocked prematurely.

No, if you do not currently obtain personal certificates and do not plan to do so in the future, there is no need for you to take any action.

We recommend that you obtain the renewed certificate accordingly via resellers. Here is a list of our resellers: ((dropdown list))

 

Note: If you previously used a personal certificate with an organisation entry, we will no longer be able to provide you with this in future. 

Identification

Yes, in all cases. Even if service providers act as technical contacts, the persons named in the certificate must be identified by a CSM operator belonging to the organisation of the person who is to be identified. For this case, an extIdent contract of the organisation must be concluded with D-Trust and the identification and verification process must be documented.

The identity of an employee must be verified beyond any doubt. Identification by the operators must be ensured before applying for a certificate, and the process must be documented within the company.

When doing this, it is possible to use the identification from the HR onboarding process, provided that the identification was completed no longer than 824 days in the past.

The processes are verified in an annual audit. This is generally done in the form of a self-audit in which the organisation answers a questionnaire provided by D-Trust. The answered questions are sent to D-Trust. This does not affect the possibility of on-site or document audits being conducted by D-Trust or an external auditor appointed by D-Trust. 

We will offer you annual operator training in this regard. In this operator training, you will find answers to these and other questions.

We are happy to help. Contact csm@d-trust.net to find out more about the permitted identification procedures.

All information on the identification processes must be stored by the organisation and kept in auditable form.

Yes. The data must be recorded and retained by the client. Transmission to D-Trust or storage in the CSM is not necessary. It must be possible to make the data accessible to D-Trust for audit purposes at any time during the retention period.

Yes.

Domain Validation

From 01.09.2023, verification of domain validation is mandatory. The same applies for already existing domains.

No, the validation is verified for the domain and is independent of the product.

Additional information: A renewed certificate can be obtained as long as the domain is verified.

No, the VS-NfD Enterprise ID is not subject to the S/MIME baseline requirements. There is no change to the previous testing practice here.

Yes, the domain check must be carried out and ensured for each organisation; even if only one domain is used for all organisations, an extended check must be completed for all organisations. This check is always carried out by D-Trust.

 

The following 6 procedures are possible for the domain check: ((dropdown subtext))

  1. Confirmation by the Domain Contact (3.2.2.4.2)

We will send the secret to the domain contact from the Whois data. Here we are often dependent on the assistance of the client because this data is no longer openly accessible, as is the case with Denic in Germany, for example. The secret must then be returned to the address specified in the email.

  1. Confirmation by Accepted Addresses of the Domain Contact (3.2.2.4.4)

We will send an email with the secret to 5 accepted email addresses: hostmaster@domain, postmaster@domain, webmaster@, admin@ and administrator@. As soon as the secret is returned to the address provided in the email, the domain will be considered validated. It does not matter from which email address the secret is returned.

  1. Change to the DNS Entry (3.2.2.4.7)

We will send an email with the secret to any email address specified by you. This secret must then be entered into the domain’s DNS in exactly the format in which we sent it. Note: It may take some time for our system to read out the new DNS entry, as the update time depends on the server.

  1. Checking whether “DNS CAA Email Contact” Exercises Control over the Domain (3.2.2.4.13)
    Our system checks whether an email address is stored in the “DNS CAA email contact” field. If this is the case, we can send the secret to this address. The secret must then be returned to the address specified in the email.
  2. Checking whether “DNS TXT Contact” Exercises Control over the Domain (3.2.2.4.14)

Our system checks whether an email address is stored in the “DNS CAA email contact” field. If this is the case, we can send the secret to this address. The secret must then be returned to the address specified in the email.

  1. Agreed Change to the Website (3.2.2.4.18)

(The method was previously known under 3.2.2.4.6 but was then technically revised.) We will send the secret to any email address named by you. The email contains a path where the secret must then be entered on the website. It is important to note that only the registered domain can be validated with this method and no subdomains.

Training

You will receive two further training reminders by email within 30 days. If you do not follow up on this, please contact csm-extident.elearningd-trust.net immediately.

Note: Once the 30-day period expires without training taking place, the identification and operator activity may no longer be carried out.

ExtIdent training is required for all products that contain personal names.

Technical Modifications

The SAN RFC822 name (email) is retained. In addition, the email subject can be filled in optionally.

No, there is no longer an OU field for standard products. 

Yes, that is correct. Only auditable sub-organisations can be entered.

The email subject and RFC822 name must be identical and will be compared. They must therefore not deviate from each other.

Fields that are no longer required are ignored at the interface, and only the relevant fields are checked. The principal name must be included in the request. 

An operator of the organisation named in the certificates must always be appointed, trained and identified by D-Trust.  Appropriate identification must be carried out for each person named in a certificate.

An Org identifier is a prerequisite for issuing certificates with an organisation entry. This is entered by D-Trust.

The specified requirements must always be met, regardless of the order channel.

CA Rollover

For S/MIME Certificates (Personal Certificates)

Due to regulatory requirements, we have to make adjustments to our current “Issuing CA” (Certificate Authority).

The background to this is the regulatory requirement to add CA/B forum-specific OID values within the CA by 14 September 2024 at the latest and the need to eventually discontinue Advanced RSA certificates with key lengths of 2048 bits.

For TLS/SSL Certificates (Server Certificates)

The background to this is the need to eventually discontinue Advanced RSA certificates with key lengths of 2048 bits.

For S/MIME Certificates (Personal Certificates)

Changes will therefore be made to our S/MIME PKI in a two-step process.

Step 1 (Intermediate Step / Interim Solution): Changed Issuing CA likely by the end of 2024

All products under the Issuing CA “D-TRUST Root CA 3 2013” will receive a new CA on 20 June 2024 (RU) and 4 July 2024 (PU). This CA will then contain additional OID values set by D-Trust. The 2048-bit key lengths will be retained for the time being. Due to regulatory requirements, this CA will likely no longer be able to issue new certificates by the end of 2024 and therefore only serves as an interim solution.

The current product names and product numbers will remain valid. The name of the CA will also remain the same. Only OID values will be added by D-Trust.

Step 2 (Final solution): new Root and Issuing CAs

In parallel with step 1, a new 4k PKI will also become available on 20 June 2024 (RU) and 4 July 2024 (PU), which will then issue RSA certificates with a key length of 3072/4096 bits.

The certificates issued from this new PKI will then contain a new product name and new product numbers, which we will inform you of as soon as possible. At the same time, there will also be an EC-based PKI with corresponding products.

For TLS/SSL Certificates (Server Certificates)

On 27 June 2024 (RU) and 11 July 2024 (PU), there will be new Root and Issuing CAs for the following RSA and EC-based server certificates:

  • Advanced DV SSL (EC)
  • Advanced SSL ID (RSA)
  • Advanced EV SSL ID (RSA)
  • Qualified EV SSL ID (RSA)

In parallel with this, the certificates created under the RSA-based Root CAs “D-TRUST Root Class 3 CA 2 EV 2009” and “D-TRUST Root Class 3 CA 2 2009” will remain in operation until 31 December 2024. Certificates issued up to this date will remain valid until the regular expiry date.

 

For S/MIME Certificates (Personal Certificates)

For the S/MIME interim solution (step 1), you do not need to adjust any product numbers for the interface-based (CMP) application. This is an effective date change where we switch to the new CA during ongoing operations. IN THIS CASE, THERE WILL THEREFORE NOT BE ANY PARALLEL OPERATION. There should be no adverse effects for you.

For step 2 (the creation of the new Root and Issuing CAs), old and new products will operate in parallel to ensure that the process goes as smoothly as possible. IN DUE COURSE, ADJUSTMENTS WILL NEED TO BE MADE TO PRODUCT NUMBERS FOR INTERFACE-BASED (CMP/ACME) APPLICATIONS

For TLS/SSL Certificates (Server Certificates)

In due course, you will need to make adjustments to product numbers in the interface-based application (CMP/ACME).

You do not need to make any adjustments. The new products will be assigned to your account by us in due course. Please be patient for a little longer.

You can download the new certificates (root & CA) from our repository. You can access our repository via the following link: https://www.d-trust.net/en/support/repository.

You can apply for EC-based certificates as an alternative. Other alternatives (e.g., shorter keys) are only available as 3k end-entity certificates (end-user certificates) with a 4k root.

No, there are already correspondingly longer key lengths that fulfill the regulatory requirements.

No, PSD2 certificates are not affected by the changes.

Please note that Apple has not yet finalised or integrated our new root CAs in their browsers. We anticipate that this will occur in the course of autumn 2024. Until then, this means that the certificates issued from the new root may be displayed as untrusted by Apple.

We therefore recommend using the old CA with new OID values for as long as possible.

In connection with the increased key lengths (3k/4k), problems based on storage space may occur with personal certificates that have been imported onto physical cards. If this concerns you, please test as soon as possible whether the problems suspected here occur for your application.  

Do you have any questions?

Piktogramm für Support
D-Trust
Support
+49 (0) 30 2598 – 0
Call us
Send e-mail
Support D-Trust Frame
Ordering Personal Certificates

Would you like to order one of our D-Trust products? Then you have come to the right place.

To ordering
Support D-Trust Frame
Support

You will find there the support you need if you have technical problems along with information on the requirements for our solutions and possible applications as well as the respective documentation and price lists.

To support