SCEP Protocol Implementation

Introduction

This document describes the Simple Certificate Enrollment Protocol (SCEP), which is a protocol used for enrollment and other Public Key Infrastructure (PKI) operations.

Enrollment and usage of SCEP generally follow this workflow:

1. Obtain a copy of the Certificate Authority (CA) certificate and validate it.
2. Generate a CSR and send it securely to the CA.
3. Poll the SCEP server in order to check whether the certificate was signed.
4. Re-enroll as necessary in order to obtain a new certificate prior to the expiration of the current certificate.
5. Retrieve the CRL as necessary.

This video gives a brief idea about the process.

API calls which we have to implement are as follows:

1. GetCACaps
2. GetCACert
3. PKCSReq

1. GetCACaps

Request

GetCACaps -: Get Certificate Authority Capabilities. The purpose of this request is to get the capabilities supported by the CA. This request is fired to the CA with no parameters :

GET /cgi-bin/pkiclient.exe?operation=GetCACaps

Response

The response contains the list of CA capabilities separated by <CR><LF> or <LF> .

2. GetCACert

Request

GetCACert -: Get Certificate Authority Certificate. The purpose of this request is to get a certificate (X.509) from the CA. The request is sent as a HTTP GET request. A packet capture for the request looks similar to this:

GET /cgi-bin/pkiclient.exe?operation=GetCACert

Response

The response is simply the binary-encoded CA certificate (X.509). The client needs to validate that the CA certificate is trusted through an examination of the fingerprint/hash. This has to be done via an out-of-band method (a phone call to a system administrator or pre-configuration of the fingerprint within the trustpoint).

3. PKCSReq

Request

PKCSReq -: Public Key Cryptography Standards Request. This request requires 2 compulsory parameters and 1 optional parameter.

1. Distinguished Name (ex. Domain name)
2. Public Key (Client)
3. challengePassword (optional)

Response

1. SUCCESS - The request is accepted and the signed certificate is included. The signed certificate is held within a special type of PKCS#7 called a "Degenerate Certificates-Only PKCS#7," which is a special container that can hold one or more X.509 or CRLs, but does not contain a signed or encrypted data payload.
2. PENDING -  The CA administrator has not reviewed the request yet.
3. REJECT -  The request is rejected by the administrator for any number of reasons, such as:

• Invalid key size
• Invalid challenge password
• The CA could not validate the request
• The request asked for attributes that the CA did not authorize
• The request was signed by an identity that the CA does not trust

Credits: Cisco