Skip to main content
Skip table of contents

Create certificate procedure in Certificate Manager

This article is valid for Certificate Manager 8.4 and later.

This article describes how to create a certificate procedure in Smart ID Certificate Manager (CM). A certificate procedure defines the parameters to be used when issuing an end-user certificate within the Certificate Authority (CA). This task is done in the Administrator's workbench (AWB) in Certificate Manager.

Prerequisites

The following prerequisites apply:

  • Two administration officers must sign the request.

  • Both officers must have the following roles:

    • Use AWB

    • Policy tasks

  • A connection to the CM host must have been established. See Connect to a Certificate Manager host.

  • The following information is required by the administration officer during the task:

    • The procedure name that will appear in the explorer bar

    • The key usage attributes required for the certificate

    • The name of the issuing CA, its CA chain if applicable, and the certificate format to be used

    • The distribution rules to be used

    • The certificate validity period and the signature algorithm required

    • If the optional extensions certificate policy, authority information access or extended key usage will be used, all the necessary object identifier (OID), qualifier and access location information must be available.

  • It is recommended that certificate formats, which are not available, be generated before performing this task.

Step-by-step instruction

Create certificate procedure

To create a certificate procedure:

  1. In AWB, select New > Certificate procedure.

  2. In the Create Certificate Procedure Request dialog, in Procedure name, enter the name to appear in the Certificate procedures sub-group in the explorer bar. This field is mandatory.

  3. Set the procedure State to Active or Closed as required.

  4. Select Domain and check Visible in subdomain if applicable.

  5. Select the Key usage parameters, if required, by checking the appropriate check boxes. It is normally not necessary to define key usage parameters. However, there are two cases when key usage restrictions for certificate procedures may be necessary:

    • when the certificate procedure is used in a token procedure that contains several certificate procedures.

    • to define the key usage required in a certificate if none are specified in the certificate request at the RA (for example, PKCS#12 tokens).
      Warning:
      Key usage must not be set if the certificate procedure should be used for issuing P12 certificates for officers. If the key usage is set, the P12 certificates may not appear in the Security dialog when trying to connect to CM.

  6. In Issuing CA, browse for the required CA. This field is mandatory.

  7. In CA chain, browse for the required CA chain.

  8. In Certificate format, browse for the required end-user certificate format. This field is mandatory.
    Note:
    Depending on the parameter settings in the certificate format file, note that, if certificate procedures validity date extends beyond that of the CA certificate's expiration date, the certificate procedure will not be visible in the RA client or the CF server can truncate the expiration date of the end-user certificate to that of the CA certificate expiration date. For more information regarding certificate formats, refer to the "Certificate Format" chapter in the Technical Description. 

  9. Once a format has been selected, you can customize the set of format definition fields and modules.

    1. At Format, click Advanced.

      1. A pop-up window will appear containing all fields and modules from the selected format file.

        • The modules are shown in the top section with their indexes in the right column (the indexes determine the execution order of the modules).

        • The format definition fields are shown in the bottom section with the values of the parameters in the right column. You can edit the values for the definition fields parameters and store them for this particular procedure.

          Here is an example with the certificate format rfc5280.

    2. To add new format definition fields or modules click Add Parameter or Add Module. For added fields and modules (that are not present in the format file) you can edit values in the left column and also remove the row with Remove Parameter or Remove Module.

    The new values will take precedence over the values in the format file, but the format file will not be affected by these changes.

  10. In Distribution rules, click + to add a distribution rule. Add all relevant distribution rules.

  11. In Distribution rules, edit the processing order if needed. To change the order, select a rule and use the arrow buttons to move it.
    The distribution rules will be processed in the order selected and then stored to CMDB.

  12. In Certificate validity, select in turn the years, months, days, hours, and minutes, and adjust the numbers with the arrows. The date and time units may also be entered manually.

  13. In Signature algorithm, select the required signature algorithm.

    Note: 
    The Signature algorithm drop-down list contains only those algorithms that matches the key algorithm for the key for the selected issuing CA.

    Warning: 
    If the hashInCis property is set to true and a signAlgorithm or signMechanism is specified for the device that holds the selected CA key, see the device configuration in cis.conf. The selected signature algorithm must be the same as the algorithm specified for the device in cis.conf. No warning message is displayed if any other signature algorithm is selected.

  14. If the warning text Signature algorithm signing key / CA key not consistent appears, do the following to troubleshoot:

    1. Right-click on the issuing CA and select Open to see the detail information about the CA.

    2. Right-click on the key and select Open to see the detail information about the key.

    3. Check which algorithm was used for the CA key and select a compatible signature algorithm, that is, an algorithm with the same key type: RSA, DSA, or ECC.

  15. There are several optional steps that can be done now, see the sections below:

    1. Optional: Define Policy ID

    2. Optional: Define authority information access

    3. Optional: Define extended key usage

  16. If QC Statements are required, go to the section "Optional: Qualified certificate statements".

  17. If the certificates issued with this certificate procedure should be covered by a special CRL distribution point, do the following:

    1. Select the CRL procedure in the CRL procedure field.

    2. Check Explicit distribution points if the issued certificates should only add the distribution points from the selected CRL procedure. For more info, see section “Partition CRL on Distribution Point” in Create CRL procedure in Certificate Manager.

  18. Specify for how long it is allowed to return an existing certificate, for identical certificate requests, in the Return existing until field. The value is specified as a percentage (nn%) of the certificate validity, default is set to 10%. Set this parameter to zero (00%) to always issue a new certificate.

  19. If the certificate renewal policy is required to be restricted, see section “Optional: Configure certificate renewal policy” below.

  20. Click OK. The Signature dialog box appears. See Sign tasks in Certificate Manager for more information.

Optional: Define policy ID

For more information on the certificate policy extension Policy ID, see RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

To add Policy ID object identifiers (OIDs), do the following for each Policy ID OID:

  1. In Policy Id, click +.

  2. In the Select Policy Id window, do the following:

    1. Enter the OID for the certificate policy to be used in the procedure being created.

    2. Optional: To use a certification practice statement, check CPS and enter the uniform resource identifier (URI) that points to the certification practice statement of the issuing CA.

    3. Optional: To send a user notice, check User notice and enter the user notice text that will be displayed in the certificate. explicitText field can contain max. 200 characters.

      Note: RFC 5280 recommends that to promote interoperability, policy information terms should consist only of the OID, but where this is insufficient only then should qualifiers be used.

  3. Click OK.

Optional: Define authority information access

For more information on the certificate policy extension Authority information access, see RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

To add authority information access pointers, do the following for each authority information access pointer:

  1. In Authority information access, click +.

  2. In the Select Authority Information Access window, do the following:

    1. Select the required Access method (OID).

    2. In Access location, select either URI or E-mail and enter the location pointer.

  3. Click OK.

Optional: Define extended key usage

For more information on the certificate policy extension extended key usage, see RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

To add extended key usages, do the following for each extended key usage:

  1. In Extended key usage, click +.

  2. In the Select Extended Key Usage window, either enter an object identifier or select the required OID from the drop-down list

  3. Click OK.

Optional: Qualified Certificate Statements

It is possible to specify qualified certificate (QC) statements within the certificate procedure. This ensures that the specified QC statements are always present within the resulting certificate, if an appropriate certificate format is used. See Qualified certificates in Certificate Manager for more detailed instructions on how to create QC statements.

QC statements are used to indicate that a certificate is issued by a qualified trust service provider and often signifies its authenticity according to a set of certificate policies. For example, certificates issued under EU eIDAS or EU PSD2 regulation. For further instruction on how to configure specific QC statements, see Qualified certificates in Certificate Manager.

Note: The QC statements stated in the certificate procedure will not override QC statements from the certificate requests. All statements entered in the certificate procedure and in the requesting client will be added to the certificate.

Optional: Configure certificate renewal policy

The certificate renewal policy defines if this procedure can be used to renew a certification of a public key or subject.

To configure certificate renewal policy:

  1. In Certificate renewal, select a rule. See the available values in the table below.

  2. In Renewal from, specify from when it is possible to renew a certificate. The validity time of all existing certificates, that are allowed by the Certificate renewal setting, must have passed the Renewal from limit. The value is specified as a percentage (nn%) of the certificate validity. The default is zero (00%), that is, always possible to renew.

    Note: 

    To always allow any renewal request, set Certificate renewal to Allowed and set Renewal from to 00%.

  3. In Key lifetime, define the validity time-span of public keys. The time-span begins at the time when the first certificate for a public key is issued. A certificate request is rejected if the lifetime of the public key has either expired or is already fully used by existing certificates. If the validity of a certificate to be issued exceeds the specified key lifetime, the certificate validity will be cut off to match the remaining lifetime. The default is zero, which means indefinite lifetime.

The following table shows the possible values for Certificate renewal:

Value

Description

Allowed

Renewal is allowed, also set Renewal from.

Allowed for the same key

Renewal of the public key is allowed, that is, the public key may be reused in a new certificate with a new subject name. The request is aborted if any valid and non-revoked certificates are issued for the same subject and purpose but with different key.

Allowed for the same subject

Renewal of the subject is allowed, that is, the subject may have several certificates, with different public keys, for the same purpose. The request is aborted if any valid certificates are issued with the same public key but for different subject.

Allowed for the same key and subject

Renewal of the public key for the same subject and purpose is allowed, for example to extend the certificate validity.

Not allowed

Renewal is not allowed. The request is aborted if any valid certificates are issued with the same public key or any valid and non-revoked certificates are issued for the same subject and purpose.

Related information


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.