17.6 Issuing a Public Key Certificate

Your Organizational CA works the same way as an external CA. That means, it has the ability to issue certificates from certificate signing requests (CSRs). You can issue certificates using your Organizational CA when a user sends a CSR to you for signing. The user requesting the certificate can then take the issued certificate and import it directly into the cryptography-enabled application.

This task allows you to generate certificates for cryptography-enabled applications that do not recognize Server Certificate objects.

To issue a certificate, perform the following steps:

  1. Click Certificate Management > Issue Certificates options from the landing page.

  2. Browse and select a CSR file.

  3. Select the appropriate Key Type and the corresponding Key Usage under Key Usage Specifications. These options allow you to select a key type. Each key type has predefined key usage values associated with it:

    1. Unspecified: This option is selected by default does not activate any key usage in the certificate.

    2. Certificate Authority: This option activates the Certificate signing and CRL signing key usages.

    3. Encryption: This option activates the Key Encipherment key usage.

    4. Signature: This option activates the Digital Signature key usage.

    5. SSL or TSL: This option configures the key so that it can be used in SSL or TLS transactions.

    6. Custom: This option lets you select any or all of the key usage options manually.

    7. Set the Key Usage Extension to Critical: With any key type except Unspecified selected, you can mark the key usage extension as critical. Any extension that is critical must be understood by the receiving software before the certificate can be used for any purpose. Therefore, marking an extension as critical does pose some risk, because not all applications can use the certificate. However, for well known extensions such as key usage, the risk is minimal. In general, if key usage is specified, the extension should be marked critical.

  4. You can choose to encode an Extended Key Usage extension in the certificate. To activate this feature, select Enable Extended Key Usage:

    1. Server: This option activates the Server Authentication extended key usage.

    2. User: This option activates the User Authentication and E-mail Protection extended key usages.

    3. Custom: This option lets you select any or all Extended Key Usages.

    4. Any: Lets the key be used for any extended key usage.

    5. Set the Extended Key Usage Extension to Critical: Any extension that is critical must be understood by the receiving software before the certificate can be used for any purpose. Therefore, marking an extension as critical does pose some risk, because not all applications can use the certificate. As many applications do not understand the Extended Key Usage Extension, marking this extension as critical poses significant risk of the certificate not being accepted by a given application; therefore, it should only be set to critical when necessary.

  5. Select the appropriate Basic Constraints:

    1. Certificate Type:

      1. Unspecified: Select this option if you do not want to add a basic constraint extension to the certificate.

      2. Certificate Authority: Select this option to add a Certificate Authority basic constraint extension to the certificate. If the certificate is for a Certificate Authority, you must select this option.

      3. End Entity: Select this option to add a basic constraint extension to the certificate that specifies this is an End Entity (that is not a Certificate Authority) certificate. Note: If a certificate is of type End Entity, the path length should be set to Unspecified.

    2. Path Length:

      1. Unspecified: Select this option if you don't want to specify how many levels of subordinate CAs can be created under this CA.

        NOTE:If a certificate is of type End Entity, the path length should only be set to Unspecified.

      2. Specific: Select this option if you want to specify how many levels of subordinate CAs can be created under this CA. Click the Up and Down-arrows to specify the path length.

        NOTE:If the certificate being created is a subordinate CA, the path length must be consistent with the superior CA. For example, if the superior CA has a path length of 3, the subordinate's path length must be 2 or less. If the superior CA has an unspecified path length, the subordinate may also have an unspecified path length or any specific path length desired.

    3. Set Basic Constraints Extension to Critical: In general, the Basic Constraints Extension must be set to critical for CA certificates. Any extension that is critical must be understood by the receiving software before the certificate can be used for any purpose. Therefore, marking an extension as critical does pose some risk, because not all applications can use the certificate. However, for well known extensions such as Basic Constraints, the risk is minimal.

  6. Specify the following certificate parameters:

    1. Subject Name: Displays the fully typed name of your OpenText eDirectory tree.

    2. Subject Name: Displays the fully typed name of your OpenText eDirectory tree.

    3. Validity Period: Use the drop-down list to specify a period over which the certificate is to be valid. The range is from 6 months to the maximum, the year 2036 (a time limitation based on a 32-bit time value). If you select the Specify Dates option, you can edit the Effective Date and the Expiration Date fields to create a custom validity period. The maximum date selected must fall within the validity date of the CA.

      1. Effective Date: Lets you display or edit the time and date when the certificate becomes valid.

      2. Expiration Date: Lets you display or edit the time and date when the certificate becomes invalid.

    4. Custom Extensions: Enables Certificate Server to support any standard or custom extensions that you want to include when creating a certificate. Extensions must have been previously created and stored in a file (one extension per file). Any extension must be ASN.1 encoded as defined in IETF RFC 2459/3280 section 4.2.

      If you want to include one or more custom extensions in the certificate you are creating, click New and then browse for a file containing the custom extension and add it to the certificate. Multiple extensions can be added by repeating this process.

      To delete a custom extentions file, select it and then click the icon.

  7. Select the appropriate certificate format from the following options:

    1. File in Binary DER Format: This option lets you save or export a certificate to a file displayed in the Filename field. By default, the certificate file is exported with a .DER extension at the root of drive C: of a Windows-based OpenText Identity Console workstation and at your home directory of a Linux-based OpenText Identity Console workstation.

    2. File in Base64 Format: This option lets you save a CSR or export a certificate to a file displayed in the Filename field. By default, the certificate and CSR files are exported with a .B64 extension at the root of drive C: of a Windows-based OpenText Identity Console workstation and at your home directory of a Linux-based OpenText Identity Console workstation.

    3. File in CER Format: This option lets you save a CSR or export a certificate to a file displayed in the Filename field. By default, the certificate and CSR files are exported with a .CER extension at the root of drive C: of a Windows-based OpenText Identity Console workstation and at your home directory of a Linux-based OpenText Identity Console workstation.

  8. Review the Summary of the certificate in the next screen and click OK.

  9. A confirmation appears indicating that the certificate has been issued successfully.