16.2. Requesting Certificates through the Console

The Certificate Setup Wizard for the CA, OCSP, KRA, and TKS automates the certificate enrollment process for subsystem certificates. The Console can create, submit, and install certificate requests and certificates for any of the certificates used by that subsystem. These certificates can be a server certificate or subsystem-specific certificate, such as a CA signing certificate or KRA transport certificate.

16.2.1. Requesting Signing Certificates

Note

It is important that the user generate and submit the client request from the computer that will be used later to access the subsystem because part of the request process generates a private key on the local machine. If location independence is required, use a hardware token, such as a smart card, to store the key pair and the certificate.
  1. Open the subsystem console. For example:
    pkiconsole https://server.example.com:8443/ca
  2. In the Configuration tab, select System Keys and Certificates in the navigation tree.
  3. In the right panel, select the Local Certificates tab.
  4. Click Add/Renew.
  5. Select the Request a certificate radio button.
  6. Choose the signing certificate type to request.
  7. Select which type of CA will sign the request, either a root CA or a subordinate CA.
  8. Set the key-pair information and set the location to generate the keys (the token), which can be either the internal security database directory or one of the listed external tokens.
    To create a new certificate, you must create a new key pair. Using an existing key pair will simply renew an existing certificate.
  9. Select the message digest algorithm.
  10. Give the subject name. Either enter values for individual DN attributes to build the subject DN or enter the full string.
    The certificate request forms support all UTF-8 characters for the common name, organizational unit, and requester name fields.
    This support does not include supporting internationalized domain names.
  11. Specify the start and end dates of the validity period for the certificate and the time at which the validity period will start and end on those dates.
    The default validity period is five years.
  12. Set the standard extensions for the certificate. The required extensions are chosen by default. To change the default choices, read the guidelines explained in Appendix B, Defaults, Constraints, and Extensions for Certificates and CRLs.

    Note

    Certificate extensions are required to set up a CA hierarchy. Subordinate CAs must have certificates that include the extension identifying them as either a subordinate SSL CA (which allows them to issue certificates for SSL) or a subordinate email CA (which allows them to issue certificates for secure email). Disabling certificate extensions means that CA hierarchies cannot be set up.
    • Basic Constraints. The associated fields are CA setting and a numeric setting for the certification path length.
    • Extended Key Usage.
    • Authority Key Identifier.
    • Subject Key Identifier.
    • Key Usage. The digital signature (bit 0), non-repudiation (bit 1), key certificate sign (bit 5), and CRL sign (bit 6) bits are set by default. The extension is marked critical as recommended by the PKIX standard and RFC 2459. See RFC 2459 for a description of the Key Usage extension.
    • Base-64 SEQUENCE of extensions. This is for custom extensions. Paste the extension in MIME 64 DER-encoded format into the text field.
    To add multiple extensions, use the ExtJoiner program. For information on using the tools, see the Certificate System Command-Line Tools Guide.
  13. The wizard generates the key pairs and displays the certificate signing request.
    The request is in base-64 encoded PKCS #10 format and is bounded by the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----. For example:
    -----BEGIN NEW CERTIFICATE REQUEST-----
    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2
    F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA
    wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz
    AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg
    JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM
    A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x
    -----END NEW CERTIFICATE REQUEST-----
    The wizard also copies the certificate request to a text file it creates in the configuration directory, which is located in /var/lib/pki/instance_name/subsystem_type/conf/. The name of the text file depends on the type of certificate requested. The possible text files are listed in Table 16.1, “Files Created for Certificate Signing Requests”.

    Table 16.1. Files Created for Certificate Signing Requests

    Filename Certificate Signing Request
    cacsr.txt CA signing certificate
    ocspcsr.txt Certificate Manager OCSP signing certificate
    ocspcsr.txt OCSP signing certificate
    Do not modify the certificate request before sending it to the CA. The request can either be submitted automatically through the wizard or copied to the clipboard and manually submitted to the CA through its end-entities page.

    Note

    The wizard's auto-submission feature can submit requests to a remote Certificate Manager only. It cannot be used for submitting the request to a third-party CA. To submit it to a third-party CA, use the certificate request file.
  14. Retrieve the certificate.
    1. Open the Certificate Manager end-entities page.
      https://server.example.com:8443/ca/ee/ca
      
    2. Click the Retrieval tab.
    3. Fill in the request ID number that was created when the certificate request was submitted, and click Submit.
    4. The next page shows the status of the certificate request. If the status is complete, then there is a link to the certificate. Click the Issued certificate link.
    5. The new certificate information is shown in pretty-print format, in base-64 encoded format, and in PKCS #7 format.
    6. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file. Save the text file, and use it to store a copy of the certificate in a subsystem's internal database. See Section 14.3.2.1, “Creating Users”.

16.2.2. Requesting Other Certificates

Note

It is important that the user generate and submit the client request from the computer that will be used later to access the subsystem because part of the request process generates a private key on the local machine. If location independence is required, use a hardware token, such as a smart card, to store the key pair and the certificate.
  1. Open the subsystem console. For example:
    pkiconsole https://server.example.com:8443/ca
    
  2. In the Configuration tab, select System Keys and Certificates in the navigation tree.
  3. In the right panel, select the Local Certificates tab.
  4. Click Add/Renew.
  5. Select the Request a certificate radio button.
  6. Choose the certificate type to request. The types of certificates that can be requested varies depending on the subsystem.

    Note

    If selecting to create an "other" certificate, the Certificate Type field becomes active. Fill in the type of certificate to create, either caCrlSigning for the CRL signing certificate, caSignedLogCert for an audit log signing certificate, or client for an SSL client certificate.
  7. Select which type of CA will sign the request. The options are to use the local CA signing certificate or to create a request to submit to another CA.
  8. Set the key-pair information and set the location to generate the keys (the token), which can be either the internal security database directory or one of the listed external tokens.
    To create a new certificate, you must create a new key pair. Using an existing key pair will simply renew an existing certificate.
  9. Give the subject name. Either enter values for individual DN attributes to build the subject DN or enter the full string.

    Note

    For an SSL server certificate, the common name must be the fully-qualified host name of the Certificate System in the format machine_name.domain.domain.
    The CA certificate request forms support all UTF-8 characters for the common name, organizational unit, and requester name fields.
    This support does not include supporting internationalized domain names.
  10. Specify the start and end dates of the validity period for the certificate and the time at which the validity period will start and end on those dates.
    The default validity period is five years.
  11. Set the standard extensions for the certificate. The required extensions are chosen by default. To change the default choices, read the guidelines explained in Appendix B, Defaults, Constraints, and Extensions for Certificates and CRLs.
    • Extended Key Usage.
    • Authority Key Identifier.
    • Subject Key Identifier.
    • Key Usage. The digital signature (bit 0), non-repudiation (bit 1), key certificate sign (bit 5), and CRL sign (bit 6) bits are set by default. The extension is marked critical as recommended by the PKIX standard and RFC 2459. See RFC 2459 for a description of the Key Usage extension.
    • Base-64 SEQUENCE of extensions. This is for custom extensions. Paste the extension in MIME 64 DER-encoded format into the text field.
    To add multiple extensions, use the ExtJoiner program. For information on using the tools, see the Certificate System Command-Line Tools Guide.
  12. The wizard generates the key pairs and displays the certificate signing request.
    The request is in base-64 encoded PKCS #10 format and is bounded by the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST-----. For example:
    -----BEGIN NEW CERTIFICATE REQUEST-----
    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2
    F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA
    wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz
    AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg
    JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM
    A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x
    -----END NEW CERTIFICATE REQUEST-----
    The wizard also copies the certificate request to a text file it creates in the configuration directory, which is located in /var/lib/pki/instance_name/subsystem_type/conf/. The name of the text file depends on the type of certificate requested. The possible text files are listed in Table 16.2, “Files Created for Certificate Signing Requests”.

    Table 16.2. Files Created for Certificate Signing Requests

    Filename Certificate Signing Request
    kracsr.txt KRA transport certificate
    sslcsr.txt SSL server certificate
    othercsr.txt Other certificates, such as Certificate Manager CRL signing certificate or SSL client certificate
    Do not modify the certificate request before sending it to the CA. The request can either be submitted automatically through the wizard or copied to the clipboard and manually submitted to the CA through its end-entities page.

    Note

    The wizard's auto-submission feature can submit requests to a remote Certificate Manager only. It cannot be used for submitting the request to a third-party CA. To submit the request to a third-party CA, use one of the certificate request files.
  13. Retrieve the certificate.
    1. Open the Certificate Manager end-entities page.
      https://server.example.com:8443/ca/ee/ca
    2. Click the Retrieval tab.
    3. Fill in the request ID number that was created when the certificate request was submitted, and click Submit.
    4. The next page shows the status of the certificate request. If the status is complete, then there is a link to the certificate. Click the Issued certificate link.
    5. The new certificate information is shown in pretty-print format, in base-64 encoded format, and in PKCS #7 format.
    6. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file. Save the text file, and use it to store a copy of the certificate in a subsystem's internal database. See Section 14.3.2.1, “Creating Users”.