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. 


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 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.


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 (

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 (

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 (

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 (
    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 (

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 (

(The method was previously known under 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.


You will receive two further training reminders by email within 30 days. If you do not follow up on this, please contact 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.

Do you have any questions?

Piktogramm für Support
+49 (0) 30 2598 – 0

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

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.