Integrate Identity Manager with D-Trust connector

The following files and details are required:

• An account at D-Trust is set up for you, and the corresponding authentication credentials for a system are available.
• The SSL certificate of the D-Trust service is available as .cer file.
• If you want key backup, you must set up a Smart ID Certificate Manager connector.

IDM 21.04 also introduces basic HTTP proxy support for the D-Trust connector. If you want it to use a specific HTTP proxy, you need the following as well: 

• hostname / IP of the proxy
• proxy port

Proxy authentication is not yet supported.

Identity Manager 23.10.3 introduces support for the D-Trust REST interface.

1. Create a dummy certificate with a new key pair with a PKCS#12 request.
   • The issuer needs to be the same as the certificate you will get from D-Trust
   • Key size needs to fit the D-Trust product
2. Use this key pair for a PKCS#10 request to D-Trust to get the real certificate.
3. Replace the dummy certificate in Smart ID Certificate Manager with the real one.
4. Set up token procedures in Certificate Manager:
   • One for certificate creation using PKCS#12 request
   • One for certificate import

5. Extend Nexus_CM.properties for the connector by entering one line:

   caTokenProcedureImportCert=<token procedure for import>

6. Set up the Certificate Manager connection for the key archive

1. Create a dtrust.properties file with the following content, depending on the transport interface:

   1. For the REST interface, which is the only officially supported one going forward:
      

      Example: dtrust.properties (using REST interface)

      CODE

      p12Path=CSMWM447922870184925_neXus_Technology_GmbH_2015_SSL.p12
      p12Password=123456
      trustStorePath=D-TRUST_SSL_Class_3_CA_1_2009.cer
      
      # note the absence of namespaceURI=... and localPart=... - you MUST NOT set those for the REST interface!
      # note the new URL for the REST interface
      url=https://csm-ref.d-trust.net/httpcmp/request
      
      certificateTemplates=TEST_SMIME_PPE;TEST_SMIME_ENT;DTrust_Recovery
      # only for key back up: map DTrust product to CM token procedure
      dtrustToCmCertificateMapping=TEST_SMIME_ENT=DEV_Encryption
      # only for key beackup: name of CM connector
      keyArchive=Key archive
      # optional proxy config
      proxyHost=proxy.mycompany.com
      proxyPort=3128

   2. For the legacy SOAP interface:
      
      

      The SOAP interface is being phased out and will eventually disappear entirely. It is no longer enabled by default on new D-Trust accounts.
      If you have a configuration still using the SOAP interface you need to reconfigure to use the REST interface (see above) as soon as possible.

      
      

      Example: dtrust.properties (using legacy SOAP interface)

      CODE

      p12Path=CSMWM447922870184925_neXus_Technology_GmbH_2015_SSL.p12
      p12Password=123456
      trustStorePath=D-TRUST_SSL_Class_3_CA_1_2009.cer
      url=https://csm-ref.d-trust.net/eonhp/csmfe
      namespaceURI=http://ws.bdr.de/csm/csm02/v1
      localPart=CmpService
      certificateTemplates=TEST_SMIME_PPE;TEST_SMIME_ENT;DTrust_Recovery
      # only for key back up: map DTrust product to CM token procedure
      dtrustToCmCertificateMapping=TEST_SMIME_ENT=DEV_Encryption
      # only for key beackup: name of CM connector
      keyArchive=Key archive
      # optional proxy config
      proxyHost=proxy.mycompany.com
      proxyPort=3128

2. Create a .zip file, with the following content:
   
   
   • dtrust.properties
   • CSMWM447922870184925_neXus_Technology_GmbH_2015_SSL.p12

   • D-TRUST_SSL_Class_3_CA_1_2009.cer

To configure the D-Trust connector into Identity Manager Admin:

1. Log in to Identity Manager Admin.
2. Go to Home > Certification Authorities (CA) and click New.

3. Enter Name of the D-Trust connector. Click Save+Edit.

4. Select Connection type D-Trust.

5. Click Upload and upload the zip file created under "Preparations" above.
   

   The zip file contains the following:

   1. dtrust.properties

      Contains P12 file path, password and connection details, required for connecting to D-Trust Certificate Authority.

   2. Client keyStore file

      Contains client key pairs and certificate details. Client keystore password is the same as defined at p12Password property of dtrust.properties. (Default password is 123456).

   3. Server certificate file

      Server certificate for accessing D-Trust CA service.

6. Click Save to save the configuration and go to the Details tab.
7. Click Search on the right hand side. All D-Trust CA certificate types are fetched and all configurable certificate types are shown. Click Apply.
   
8. Click Testing. All connections should be green.
   
9. Click Save.

The D-trust CA does not provide the valid certificate templates, so you must configure them manually.

• Edit dtrust.properties and enter the certificateTemplates as a single String. Use semicolon (";") as a delimiter.

  Example: dtrust.properties

  certificateTemplates=TEST_SMIME_PPE;TEST_SMIME_ENT

  

  If this property (in the properties files) is empty or missing, the D-Trust connector will fail to start when Tomcat starts with deployment.

The D-Trust CA has an advanced validation of the certificate attributes. Thus even test certificates need to get valid data. The exact rules are documented in the management portal of the D-Trust Certificate Authority under the menu entry 'pre-validated data'. In the details view (click the eye) you can select a product to view. The management portal can be reached via https://mycsm.d-trust.net/csm/.

Most of the error messages are rather clear, but a few are hard to decode:

• GENERIC_RDN_REGEXERROR can have various reasons, for example:
  
  • There are deliveries with certificate templates that accidentally contains 'CN=' within the CN attribute. That needs to be removed.
  • The D-Trust certificate type ("product") is configured to require the organisationIdentifier attribute in the DN, but that attribute is not yet set in your D-Trust account. 
    
• EMAILDOMAIN_DOES_NOT_FIT can be caused by setting an email address as SAN or in the DN, which uses a domain that is not (fully) verified.
• Invalid request (certificate request type does not seem to match its content). Either a PKCS10 type was used without the inclusion of a PKCS10 request, or a PKCS12 type was used with the inclusion of a PKCS10 request. Review the certificate request information.
  The token procedures of the Nexus Certificate Manager used to create the archived keys need to be configured to handle PKCS#10 requests.
• NullPointerException in de.nexus.dTrustConnector.request.DTrustPasswordGenerator
  For the internal connector it is possible to pass a revocation password when creating the certificate and manage it in the process (see below). But if no revocation password is set, it gets generated from the CN, thus the CN needs to be provided.
• GENERIC_PASSWORD_REGEXERROR happens because a revocation password does not fit the requirements of the particular certificate type ("product").
  In such cases you need to configure the REVOCATION_PASSWORD parameter in the IDM certificate template and revocation request data.
  The value needs to be sourced from a secret (REF) field holding a previously generated password that fits the requirements.
  See Credentials: Generate Random Password in Credentials - Standard service tasks in Identity Manager for a service-task than can be used for password generation.
  
  

  In general it is recommended to generate the revocation password in the process when issuing new certificates. Having the D-Trust connector generate it based on the CN should only be used for revoking already existing certificates without a stored revocation password (for backwards-compatibility).