- Created by Karolin Hemmingsson (Unlicensed), last modified by Ann Base (Deactivated) on Oct 08, 2020
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 2 Next »
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.
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 file may contain sensitive information, for example, the pin code for tokens, which should be protected.
- Add the keyword
.encrypted
to the configuration parameter. - The next time the service starts it scans the configuration file for unscrambled values, scrambles the values and saves the updated file to disk.
This feature is not limited to cm.conf . It can also be used in kar.conf, cis.conf or da.conf.
*.pin = 1234
is considered to be sensitive. To scramble the parameter rename it to *.pin.encrypted = 1234
.
After the restart the value will have changed to *.pin.encrypted = encrypted:MCa12==
.
When scrambling a configuration file, a *.seed file is created. This file contains information needed for the installer to be able to decrypt the sensitive data during installation. The file is stored in the same folder as the corresponding configuration file.
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.
- In the certificate format file being used, add the new modifier(s) after modifier
Id2Legacy
but before modifierId2Signer1
. This is so that the transport certificate can be verified before the signing takes place.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.
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.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
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
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.ExpirationCheck
specifies to what extent the checking should be performed.Critical
specifies if the transport certificate is mandatory.
- CM is shipped with a sample transport certificate named tcsigner.cer. To 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
- No labels