Question

Difficulty: MediumPublic Key Infrastructure and Certificate Management

A network security administrator is commissioning a new internal web application server that requires a trusted SSL/TLS certificate signed by the enterprise internal Certificate Authority (CA). Which of the following sequences represents the correct chronological order of steps the administrator must perform to obtain and deploy this certificate?

  1. 1Generate a new asymmetric key pair locally on the target web server.
  2. 2Create a Certificate Signing Request (CSR) containing the public key and identity attributes such as the Subject Alternative Name (SAN).
  3. 3Submit the generated CSR to the internal Certificate Authority for validation and digital signature issuance.
  4. 4Install the issued public server certificate along with the intermediate CA certificate chain on the web server.

Answer

The correct operational sequence begins with generating the private/public key pair locally on the server, followed by creating the Certificate Signing Request (CSR) with identity details, submitting the CSR to the CA for verification and signing, and finally installing the signed certificate along with the intermediate CA trust chain on the server.
The proper PKI enrollment workflow begins by locally generating the asymmetric key pair on the web server to ensure private key protection. Next, a Certificate Signing Request (CSR) containing the public key and identity specifications (like SAN extensions) is created. This CSR is then submitted to the Certificate Authority (CA) for verification and signing. Finally, once signed, the certificate along with the intermediate CA certificates are installed on the server to enable valid TLS connections.

Step-by-Step Solution

1
Generate local key pair
Private key stays secret on the server while the public key is ready for submission
Security best practices dictate that private keys must be generated locally and never transmitted across the network.
2
Formulate the CSR
A CSR file formatted with public key data and Subject Alternative Name (SAN) extensions
The CSR provides the CA with the required server identity attributes and public key to be bound into the certificate.
3
Submit CSR to CA for signing
The CA validates request parameters and generates a signed public certificate
The CA asserts trust by appending its cryptographic signature using its private key.
4
Deploy certificate and intermediate chain
Web server is fully configured for TLS trust and handshakes
Installing both the server certificate and intermediate certificates ensures client browsers can validate the entire trust path to the root CA.

Key Concept

Public Key Infrastructure Certificate Lifecycle and Request Workflow
Rate this question