5.4. Requesting and Receiving Certificates


As explained in Section 5.1, “About Enrolling and Renewing Certificates”, once CSRs are generated, they need to be submitted to the CA for issuance. Some of the methods discussed in Section 5.2, “Creating Certificate Signing Requests” submit CSRs to the CA directly, while some would require submission of the CSRs in a separate step, which could either be carried out by the user or pre-signed by an agent.
In this section, we are going to discuss the separate submission steps supported by the RHCS CA.

5.4.1. Requesting and Receiving a Certificate through the End-Entities Page

At the CA End Entity portal (i.e. https://host.domain:port#/ca/ee/ca), end entities can use the HTML enrollment forms presented at each applicable enrollment profile under the Enrollment/Renewal tab to submit their certificate requests (CSRs, see Section 5.2, “Creating Certificate Signing Requests” for how to generate CSRs).
This section assumes that you have the CSR in Base64 encoded format, including the marker lines -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST----- .
Many of the default enrollment profiles provide a Certificate Request text box where one could paste in the Base64 encoded CSR, along with a Certificate Request Type selection drop down list.
In the certificate enrollment form, enter the required information.
The standard requirements are as follows:
  • Certificate Request Type. This is either PKCS#10 or CRMF. Certificate requests created through the subsystem administrative console are PKCS #10; those created through the certutil tool and other utilities are usually PKCS #10.
  • Certificate Request. Paste the base-64 encoded blob, including the -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST----- marker lines.
  • Requester Name. This is the common name of the person requesting the certificate.
  • Requester Email. This is the email address of the requester. The agent or CA system will use this address to contact the requester when the certificate is issued. For example, jdoe@someCompany.com.
  • Requester Phone. This is the contact phone number of the requester.
The submitted request is queued for agent approval. An agent needs to process and approve the certificate request.

Note

Some enrollment profiles may allow automatic approval such as by using the LDAP uid/pwd authentication method offered by Red Hat Certificate System. Enrollments through those profiles would not require manual agent approval in the next section. See Chapter 9, Authentication for Enrolling Certificates for supported approval methods.
In case of manual approval, once the certificate is approved and generated, you can retrieve the certificate.
  1. Open the Certificate Manager end-entities page, for example:
    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.
    The following actions can be taken through this page:
    • To install this certificate on a server or other application, scroll down to the Installing This Certificate in a Server section, which contains the base-64 encoded certificate.
  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 the security module of the entity where the private key resides. See Section 14.3.2.1, “Creating Users”.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.