Skills Tested
Configuring and enabling the Cisco IOS certificate server. This CA will issue end entity
certificates to other devices in the topology using Cisco Simple Certificate Enrollment Protocol (SCEP).
Configure other elements in the network as required to allow HTTP access to R1. HTTP is the transport for the SCEP messages.
Solution and Verification
The major criteria to verify for this exercise are the parameters on the CA server and the availability of the server from the perspective of the end entities in the network. This requires HTTP traffic to be allowed through the ASA1/c2 destined to R1. Cisco devices use SCEP for the authentication of the CA and enrollment of end entities using X.509-based certificates. In addition, other vendors, such as Microsoft, have implemented SCEP as a registration authority (RA), which acts as a translator
between the Microsoft CA server and SCEP-based end entities.
For all verification syntax that follows:
Required output appears in red Required tasks appear in indigo Variable syntax appears in green
Verify whether the HTTP server is enabled on R1.
Click here to view code image
R1# show ip http server status HTTP server status: Enabled
HTTP server port: 80
Allow HTTP through the Cisco ASA:
Click here to view code image
ASA1/c2# show run | include www
access-list 101 extended permit tcp any any eq www
Verify whether R1 is synchronized to a reliable time source. Certificates have a specified lifetime, and any issues with incorrect time can render a credential invalid.
Click here to view code image
R1# show ntp stat
Clock is synchronized, stratum 4, reference is 10.50.70.5
Before the certificate server can be configured and enabled, the CA itself must generate a
public/private key pair that will be used to validate its own identity. When an end entity wishes to enroll with the CA it will request the CA’s public key. The key information is verified as follows:
Click here to view code image
R1# show cry key mypubkey rsa
% Key pair was generated at: 22:12:36 UTC Jul 17 2012 Key name: ciscoca
Key type: RSA KEYS
Storage Device: private-config Usage: General Purpose Key Key is exportable.
The public key of the CA is distributed to the end entity in the form of a CA certificate, which is
generated during the CA server configuration process. Verify whether the CA certificate has a lifetime of 1 year and the certificate itself is stored in NVRAM:
Click here to view code image
R1# show cry pki certificates CA Certificate
Status: Available
Certificate Serial Number (hex): 01 Certificate Usage: Signature
Issuer:
cn=ciscoca.cisco.com L=cisco C=US Subject:
cn=ciscoca.cisco.com L=cisco C=US Validity Date:
start date: 13:19:37 PST Aug 17 2013 end date: 13:19:37 PST Aug 17 2014 Associated Trustpoints: ciscoca
Storage: nvram:ciscocacisco#1CA.cer
To verify whether the CA server is ready to service end entities, make sure the server itself is enabled. By default, the CA server state is shut down.
When the end entity requests the CA cert, it will use crypto ca authenticate ciscoca, where ciscoca is the trustpoint name used in this question. In response, the CA will send its certificate along with a CA cert fingerprint. If the end entity trusts that the certificate is from the CA, it will accept the
certificate based on accepting the fingerprint (hashed value derived from the CA cert). The fingerprint sent by the CA must match the fingerprint as it appears in the output of the show crypto pki server command (this value will vary). The chain of trust is now established between the end entity and CA.
The end entity will now use the crypto ca enroll ciscoca command to send its public key and identity information (CN, IP address, and so on) to the CA. The CA will issue a certificate based on this information and return it to the end entity signed with its private key. Using the concept of digital signatures, the end entity will verify whether the issued certificate has come from the trusted CA by decrypting the private key signed digital signature with the CA’s public key. Remember that the public key was received by the end entity during the CA authentication step.
Click here to view code image
R1#(config)crypto pki server ciscoca no shutdown
R1# show crypto pki server Certificate Server ciscoca:
Status: enabled State: enabled
Server's configuration is locked (enter "shut" to unlock it) Issuer name: CN=ciscoca.cisco.com L=cisco C=US
CA cert fingerprint: 1F5A02E4 C2C8230A 56FC15BB CBDFBEF6 Granting mode is: auto
Last certificate issued serial number (hex): 1
CA certificate expiration timer: 13:19:37 PST Aug 17 2014 CRL NextUpdate timer: 13:10:07 PST Sep 8 2013
Current primary storage dir: nvram:
Database Level: Minimum - no cert data written to storage Configuration
R1
Click here to view code image
crypto key generate rsa general-keys label ciscoca exportable
!
crypto key export rsa ciscoca pem url nvram: 3des cisco123
!
crypto pki server ciscoca
issuer-name CN=ciscoca.cisco.com L=cisco C=US grant auto
lifetime crl 24
lifetime certificate 200 lifetime ca-certificate 365
crypto pki token default removal timeout 0
!
crypto pki certificate chain ciscoca certificate ca 01
<cert omitted>
ASA1/c2
Click here to view code image
access-list 101 permit tcp any any eq www access-group 101 in interface outside
Tech Notes
Simple Certificate Enrollment Protocol (SCEP) is the subject of an IETF informational draft that has the status of historic. It is used as a reference for those wishing to implement this protocol to handle X.509 certificates.
This document includes the definitions for the messages covered briefly in the solution review:
Get CA Certificate: Sent in the clear using HTTP as a transport protocol.
CA Certificate Response: Return an X.509 certificate authenticated with a fingerprint derived by calculating an MD5 or SHA hash over the entire certificate.
PKCSReq—Enrollment Request: PKCS#10 cert request secured with a PKCS#7 envelop using a challenge password.
PKCSReq Response—Enrollment Response: X.509 certificate secured with PKCS#7 envelop using CA private key.
The informational draft also outlines how CRLs are handled with SCEP.
Section 4: System Hardening and Availability
System or device hardening involves implementing techniques that protect against compromise
resulting in either specific device/system failure or disruption to other network services. The goal of enabling protection and monitoring features on a system is performance predictability and network availability. The exercises in this section require implementing and troubleshooting specific
hardening features such as control and management plane policing. Features that focus on network availability, such as routing protocol security, monitoring traffic transiting a switch, and securing wireless infrastructure, are also covered.