This is part two of my article about NDES and Cisco. In the first article, I configured the Windows 2012 NDES role, in this part I will walk you through the enrollment process on a Cisco IOS router.
So what are we going to do here? We will be leveraging SCEP to obtain a digital certificate from a CA. As a prerequisite to this, the router needs a key-pair, that is, private and public keys. The public key will be sent to the CA (using SCEP), the CA will sign that public key and send the certificate (signed public key) back to the router.
If you are already using services like “ssh” or “ip http secure-server” you can use the existing keys. If no keys exist, the router will create a new set of keys as we enroll for a certificate. This auto generated key-pair is only using a 512 bit key, that is not considered secure anymore.
To create a new key-pair, using a reasonable secure key length:
Having the keys in place, we need to get the CA certificate. The router will use the CAs public key to authenticate the CA and other digital certificates issued by that same CA.
To download the CA certificate we define a new trustpoint and set to enrollment URL to the SCEP URL, if you have no name resolution configured, be sure to use the IP address of the SCEP server instead of the name.
The SCEP URL defaults to: http://servername:80/CertSrv/mscep/mscep.dll
After configuring the trustpoint, we tell the router to download the CA certificate:
IOS shows the Thumbprint (fingerprint) of the digital certificate, so one could verify that this is the correct certificate using an out-of-band method.
A quick look at the running-config shows that the key was received.
Now that the router does trust our CA we can go ahead and request a digital certificate:
IOS prompts for a password that would be used to revoke the certificate, and you can choose to add the IP address or serial number to the certificate.
The request gets signed by the CA and the certificate is sent back to the router, you should see the following messages in the log or on “terminal monitor”
CRYPTO_PKI: Certificate Request Fingerprint MD5: 4C9C472F 605AA33F 869EB167 9F097C56
CRYPTO_PKI: Certificate Request Fingerprint SHA1: E943141D 19A5C4EB 6B5EE5D2 B87AAF57 B829FFED
%PKI-6-CERTRET: Certificate received from Certificate Authority
The IIS Log on the SCEP server shows the successful transaction like this:
2012-11-30 18:58:19 192.168.1.21 GET /CertSrv/mscep/mscep.dll/pkiclient.exe operation=PKIOperation&message=MIIJUgYJKoZIhvcNAQcCoIIJQzCCCT8CAQExDjAMBggqhkiG…
…2Bw6Q1AJGzQs4wl7jA4GvWvikdP1wnPzAkVP7KZ%2FZ1%2Fz4hCYNpP4%3D%0A 80 - 192.168.1.1 - - 200 0 0 277
In the “Certificate Authority” MMC Snap-In you see the certificates that have been issued:
That was the second, and final part on NDES and IOS routers.