Version 4.1 - 2.0 CEP
CEP is the Certificate Enrollment Protocol. You will normally see this as SCEP. It was developed by Cisco and is an IETF Internet Draft (actually many versions of this with the IETF - drafts are only good for up to 6 months). The Cisco Doc on SCEP is a really good overview if you have no background with PKI. Fortunately, I have been working with PKI for over a decade. [That MCSE background sure comes in handy sometimes.]
Since PKI is covered in a separate section, I'm going to try to limit this post to just items relevant to SCEP. The Cisco Doc lists its main characteristics as:
++ Request/response model based on HTTP (GET method; optional support for POST method)
++ Only supports RSA-based cryptography
++ Uses PKCS#10 as the certificate request format
++ Uses PKCS#7 in order to convey cryptographically signed/encrypted messages
++ Supports asynchronous granting by the server, with regular polling by the requester
++ Has limited Certificate Revocation List (CRL) retrieval support (preferred method is CDP query)
++ Does not support online certificate revocation (must be done offline through other means)
++ Requires the use of a challenge password field within the CSR
Since there are STEPS to this, they may be important (possible drag-and-drop):
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.
The response to an enrollment is Reject, Pending or Success. I know a lot of this is going to be covered under the PKI section, so I'm going to keep this somewhat short and sweet. Remember that you are doing this to obtain a (CA) signed certificate. This certificate will be used for things like certificate-based authentication. The most important part of this (IRL) is that you generate a CSR with the proper DN that you are going to use and you must know the purpose of the certificate. Also know that if you want your certificate to be accepted, the recipient must trust the CA that signed your certificate. [Chain of Trust] The certificate is actually your public key - that has been signed by a trusted Certificate Authority.
When you copy and paste the certificate request, make sure you include the BEGIN and END portions - and not just the text between them.
-----BEGIN CERTIFICATE REQUEST-----
MIICqjCCAZIC
... (edited for brevity)
H4DyYdH7x5jzHc=
-----END CERTIFICATE REQUEST-----
If you change the hostname or domain name on the router, switch, etc, you must crypto key zeroize, generate a new key and submit a new CSR. I highly suggest that if you get a question on this, read it very carefully. In practice, you will probably have a Root CA that is a Microsoft Server somewhere on your Active Directory. This section (and possibly on the test) is making the assumption that the Root CA has signed the certificate (or even self-signed) for a router somewhere to run SCEP. IF you are not used to this, Cisco has a document that covers this in detail. The specific section of this document that applies is titled "Configure and Enroll the Second IOS Router (R2) to the Certificate Server." My only irritation with this example is that they use "cisco" as the trustpoint name. [Lower case is normally used for commands and best practices suggest to use CAPS for names like access-list names, crypto-map names, etc. That way it's obvious that it is a NAME rather than a command.]