Visit Nexus to get an overview of Nexus' solutions, read customer cases, access the latest news, and more.


The Smart ID Certificate Manager (CM) servers, indicated by the acronym CF (Certificate Factory) comprises several sub-components that may be loaded into the same computer or distributed to several computers in order to obtain higher performance.

The following sub-components are included when option CF is selected in the installation procedure:

  • Certificate Factory (CF)
  • CRL Factory (CRLF)
  • Publication Factory (PF)
  • Key Archiving and Recovery Factory (KARF)
  • Expiry Check Service (ECS)
  • PIN Protection Manager (PPM)

The configuration description in this chapter is Windows-oriented.

Expand/Collapse All

Configuration files

The configuration files of CF are found in <configuration_root>/config. The main configuration file is cm.conf. The operation of CF is controlled by parameters in this well commented file. 

Prerequisites

Date, time and time zone settings (in the Control Panel) must be the same on both the Certificate Issuing System (CIS) and CF.

Step-by-step instructions

You can configure CF to:

  • run CIS internally within the CF service, or
  • connect to an external independent CIS service located on a separate or on the local machine.

Options for CIS

  • If you do not select CIS to be installed during the installation, the installation program will configure CF to run CIS internally by default.
  • If you select to install CIS together with CF, the installation program will configure CF to connect to the external CIS service on the local machine. 

To manually change this after the installation, modify the value of cis.hostport in cm.conf.

Distributed configuration

  • When running in a distributed production configuration, update the localhost name in the parameter Database.name

The configuration files, for example cm.confkar.conf, cis.conf and da.conf, may contain sensitive information, such as PIN codes for tokens. Such sensitive data can be protected by scrambling. 

To scramble a configuration parameter in a configuration file, add the keyword .encrypted to the configuration. The next time the application starts, it scans the file for unscrambled values and scrambles them, and then saves the updated file to the disk.

Example 

The parameter *.pin = 1234 is considered sensitive and therefore should be scrambled. To scramble the parameter, add .encrypted to it:

Example: Encrypt parameter
*.pin.encrypted = 1234

The server will find the unscrambled value and scramble it:

Example: Resulting encrypted parameter
*.pin.encrypted = encrypted:MCa12==


The scrambling will create .seed files that must not be deleted, or the scrambled value can not be unscrambled.

You can configure CF to process certificate requests that include transport certificates. A special modifier in CF needs to be configured in order to verify the transport certificate.

  1. In the certificate format file being used, add the new modifier(s) after modifier Id2Legacy but before modifier Id2Signer1. This is so that the transport certificate can be verified before the signing takes place.
    1. These are examples of two configured transport certificate modifiers:
      TransportCertificateA=<m>
      TransportCertificateB=<n>
      where <m> and <n> are correct sequence numbers.

      All sequence numbers that follow TransportCertificate must be incremented.

  2. The processing and checking performed by this modifier is controlled by parameters in a configuration file, for example, tcconfig.conf, pointed to by parameter InitData in either the default module table, or a customized entry in modules.conf

    1. This example shows an extract from modules.conf:

      Example: Extract from modules.conf
      ;;
      ;; Transport Certificate
      ;;
      ;; Used to verify that generated key pairs where generated by
      ;; a trusted CA
      ;;
      [TransportCertificate]
      FileName=com.id2tech.cm.cf.modifiers.TransportCertificateModifier
      InitData=config/tcconfig.conf
    2. This is an example of a configuration file:

      Example of a configuration file
      ;;
      ;; Configuration file for trusted certificates.
      ;; File: tcconfigA.conf
      ;; Version: x.x
      ;; Date: 200x-xx-xx
      ;;
      ;; Location of CA certificate, relative to file or
      ;; an absolute path.
      ;CA-cert=..\certs\tcsigner.cer
      CA-cert.1=..\certs\tccert_org1.crt
      CA-cert.2=..\certs\tccert_org2.crt
      ;;
      ;; ExpirationCheck (default false)
      ;; Set to true if CA certificates and transport certificates
      ;; are to be checked for validFrom and validTo.
      ;;ExpirationCheck=true
      ;;
      ;; If no transport certificate sent from RA, modifier will
      ;; succeed if it isn't critical (default false)
      ;;
      critical=true
      1. CA-cert specifies which CA certificates to use when verifying the transport certificate. If more than one CA certificate is accepted they must be numbered as in the example. Alternatively, the parameter can be a path to a directory where the DER coded CA certificates are stored.
      2. ExpirationCheck specifies to what extent the checking should be performed.
      3. Critical specifies if the transport certificate is mandatory.
  3. CM is shipped with a sample transport certificate named tcsigner.cerTo use transport certificates, replace this sample certificate by another one and update the parameter ca-cert in tcconfig.conf accordingly.

    Example:

    CA-cert=<configuration_root>/certs/tcsigner.cer

The mapping of individual labels to use custom keys is described in the Technical Description where the necessary configuration changes are shown in chapter “Certificate Formats”.

The configuring of the Revocation Password function is described in detail in the Technical Description.

Related information