The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the Simple Certificate Enrollment Protocol (SCEP), which is a protocol used for enrollment and other Public Key Infrastructure (PKI) operations.
SCEP was originally developed by Cisco, and is documented in an Internet Engineering Task Force (IETF) Draft.
Its main characteristics are:
Enrollment and usage of SCEP generally follows this work flow:
SCEP uses the CA certificate in order to secure the message exchange for the CSR. As a result, it is necessary to obtain a copy of the CA certificate. The GetCACert operation is used.
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
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).
The enrollment request is sent as a HTTP GET request. A packet capture for the request looks similar to this:
/cgi-bin/pkiclient.exe?operation=PKIOperation&message=
MIIHCgYJKoZIhvcNAQcCoIIG%2BzCCBvcCAQExDjA......<snip>
The response to the SCEP enrollment request is one of three types:
Prior to certificate expiration, the client needs to get a new certificate. There is a slight behavioral difference between renewal and rollover. Renewal happens when the ID certificate of the client approaches expiration, and its expiration date is not the same (earlier than) as the expiration date of the CA certificate. Rollover happens when the ID certificate approaches expiration, and its expiration date is the same as the CA's certificate expiration date.
As the expiration date of an ID certificate approaches, a SCEP client might want to obtain a new certificate. The client generates a CSR and goes through the Enrollment process (as defined previously). The current certificate is used in order to sign the SignedData PKCS#7, which in turn proves identity to the CA. Upon reciept of the new certificate, the client immediately deletes the current certificate and replaces it with the new one, whose validity starts immediately.
Rollover is a special case where the CA certificate expires and a new CA certificate is generated. The CA generates a new CA certificate which becomes valid once the current CA certificate expires. The CA usually generates this "Shadow CA" certificate some time prior to rollover time, because it is needed in order to generate "Shadow ID" certificates for the clients.
When the SCEP client's ID certificate approaches expiration, the SCEP client queries the CA for the "Shadow CA" Certificate. This is done with the GetNextCACert operation as shown here:
GET /cgi-bin/pkiclient.exe?operation=GetNextCACert
Once the SCEP client has the "Shadow CA" certificate, it requests a "Shadow ID" certificate after the normal enrollment procedure. The CA signs the "Shadow ID" certificate with the "Shadow CA" certificate. Unlike a normal renewal request, the "Shadow ID" certificate that is returned becomes valid at the time of CA certificate expiration (rollover). As a result, the client needs to keep a copy of the pre- and post-rollover certificates for both the CA and the ID certificate. At the time of CA expiration (rollover), the SCEP client deletes the current CA certificate and ID certificate and replaces them with the "Shadow" copies.
This structure is used as the building blocks of SCEP.
Note: PKCS#7 and PKCS#10 are not SCEP-specific.
PKCS#7 is a defined data format that allows data to be signed or encrypted. The data format includes the original data and the associated metadata necessary in order to perform the cryptographic operation.
The signed envelope is a format that carries data and confirms that the encapsulated data is not altered in transit via digital signatures. It includes this information:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
The data encapsulated is not encrypted or obfuscated. This format simply provides protection against the message that is altered.
The Enveloped Data format carries data that is encrypted and can only be decrypted by the specified recipient(s). It includes this information:
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
PKCS#10 describes the format of a CSR. A CSR contains the information that clients request be included within their certificates:
Here is an example of a CSR:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=scepclient
Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public-Key: (1024 bit)
Modulus:
00:cd:46:5b:e2:13:f9:bf:14:11:25:6d:ff:2f:43:
64:75:89:77:f6:8a:98:46:97:13:ca:50:83:bb:10:
cf:73:a4:bc:c1:b0:4b:5c:8b:58:25:38:d1:19:00:
a2:35:73:ef:9e:30:72:27:02:b1:64:41:f8:f6:94:
7b:90:c4:04:28:a1:02:c2:20:a2:14:da:b6:42:6f:
e6:cb:bb:33:c4:a3:64:de:4b:3a:7d:4c:a0:d4:e1:
b8:d8:71:cc:c7:59:89:88:43:24:f1:a4:56:66:3f:
10:25:41:69:af:e0:e2:b8:c8:a4:22:89:55:e1:cb:
00:95:31:3f:af:51:3f:53:ad
Exponent: 65537 (0x10001)
Attributes:
challengePassword :
Requested Extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:webserver.example.com
Signature Algorithm: sha1WithRSAEncryption
8c:d6:4c:52:4e:c0:d0:28:ca:cf:dc:c1:67:93:aa:4a:93:d0:
d1:92:d9:66:d0:99:f5:ad:b4:79:a5:da:2d:6a:f0:39:63:8f:
e4:02:b9:bb:39:9d:a0:7a:6e:77:bf:d2:49:22:08:e2:dc:67:
ea:59:45:8f:77:45:60:62:67:64:1d:fe:c7:d6:a0:c3:06:85:
e8:f8:11:54:c5:94:9e:fd:42:69:be:e6:73:40:dc:11:a5:9a:
f5:18:a0:47:33:65:22:d3:45:9f:f0:fd:1d:f4:6f:38:75:c7:
a6:8b:3a:33:07:09:12:f3:f1:af:ba:b7:cf:a6:af:67:cf:47: 60:fc
Requests are sent with an HTTP GET of the form :
GET CGI-path/pkiclient.exe?operation=operation&message=message HTTP/version
Where:
With the GET method, the message part is either plain text, or Distinguished Encoding Rules (DER)-encoded PKCS#7 converted to Base64. If the POST method is supported, content that would be sent in Base64 encoding with GET might be sent in binary format with POST instead.
Possible values for operations and their associated message values:
PKIOperation
:
SCEP responses are returned as standard HTTP content, with a Content-Type that depends on the original request and the type of data returned. DER content is returned as binary (not in Base64 as for the request). PKCS#7 content might or might not contain encrypted/signed enveloped data; if it does not (only contains a set of certificates), it is referred to as a degenerate PKCS#7.
Possible values for Content-Type:
application/x-pki-message:
application/x-x509-ca-cert:
application/x-x509-ca-ra-cert:
application/x-x509-next-ca-cert:
2.16.840.1.113733.1.9.2 scep-messageType
2.16.840.1.113733.1.9.3 scep-pkiStatus
2.16.840.1.113733.1.9.4 scep-failInfo
2.16.840.1.113733.1.9.5 scep-senderNonce
2.16.840.1.113733.1.9.6 scep-recipientNonce
2.16.840.1.113733.1.9.7 scep-transId
2.16.840.1.113733.1.9.8 scep-extensionReq