Examkin

Question

Difficulty: MediumPublic Key Infrastructure and Certificate Management

A systems administrator is configuring a newly deployed internal web portal to serve traffic over HTTPS using a certificate issued by the organization's Enterprise Certificate Authority (CA). Place the administrative steps in the correct chronological order required to successfully enroll and enable the TLS certificate on the web portal.

  1. 1Generate a new asymmetric key pair locally on the web portal server.
  2. 2Construct a Certificate Signing Request (CSR) containing the portal's public key and Subject Alternative Name (SAN) attributes.
  3. 3Submit the generated CSR to the Enterprise Certificate Authority for identity validation and signing.
  4. 4Import the issued X.509 leaf certificate and intermediate CA certificate chain onto the web portal server.
  5. 5Bind the X.509 certificate to the web portal server's HTTPS daemon listener on port 443.

Answer

The correct chronological order for enrolling and enabling a TLS certificate is: 1) Generate the local key pair, 2) Construct the Certificate Signing Request (CSR) with public key and SAN, 3) Submit the CSR to the Certificate Authority (CA), 4) Import the issued X.509 certificate and intermediate trust chain onto the server, and 5) Bind the certificate to the web daemon HTTPS listener.
The correct order follows the standard PKI certificate lifecycle. The key pair must be generated on the destination server first to ensure private key protection. The public key is bundled with domain identity parameters (such as the SAN extension) into a CSR. The CSR is transmitted to the CA for signing. After the CA returns the signed X.509 leaf certificate along with intermediate CA certificates, they are imported to the server. Finally, the web service daemon is configured to bind the certificate to port 443 to accept secure incoming HTTPS connections.

Step-by-Step Solution

1
Generate Key Pair locally
A secure private key is retained locally while the matching public key is prepared for inclusion in the request.
Security best practices demand that private keys are generated locally on the end system to prevent key exposure during transit.
2
Create Certificate Signing Request (CSR)
A CSR payload containing identity details (SAN, CN) and the public key is produced.
The CSR acts as the standardized request format that the Certificate Authority processes.
3
Submit CSR to the Certificate Authority (CA)
The CA signs the public key and identity data using its own private key, producing a valid X.509 certificate.
Only a trusted CA can vouch for the authenticity of the server's public key.
4
Import Certificate and Intermediate Chain
The server stores the signed leaf certificate and establishes the chain of trust back to the root CA.
Clients connecting to the server require both the leaf certificate and intermediate certificates to validate the signature hierarchy.
5
Bind Certificate to Port 443 HTTPS Listener
The web daemon presents the installed certificate during incoming TLS handshakes.
Binding connects the network interface daemon to the stored certificate and corresponding private key.

Key Concept

PKI Certificate Lifecycle and CSR Enrollment Workflow
Rate this question

Topics

Public Key Infrastructure and Certificate Management

More questions from this topic