Basic certificate usage on a Cisco IOS web server - Part 2

In this part, we will address the two errors we’ve encountered in the first example:

-          The self-signed certificate

-          The signature algorithm

I’ve made a basic set up in GNS3:

R1 will be the CA root; R2 becomes the client.

After basic interface and hostname config, we will set the clock. This is one of the most important things to do, since the certificate validity is based on time/date!

R1(config)#clock timezone AMS 1

R1(config)#exi

R1#clock set 12:57:00 january 5 2014

We will do the same on R2:

R2(config)#clock timezone AMS 1

R2#clock set 12:57:00 january 5 2014

*Jan  5 11:57:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:19:01 AMS Fri Mar 1 2002 to 12:57:00 AMS Sun Jan 5 2014, configured from console by console.

Basic root CA config:

R1(config)#crypto pki server R1-root

R1(cs-server)#grant auto

we will automatically assign a certificate after a request.

Jan  4 10:44:00.267: %PKI-6-CS_GRANT_AUTO: All enrollment requests will be automatically granted.

R1(cs-server)#hash sha256

This will address the signature algorithm issue. Cisco IOS will always use MD5 as a default.

R1(cs-server)#issuer-name cn=R1

We will give de CA a really basic name, in a real environment this will be much more descriptive.

R1(cs-server)#no shut

%Some server settings cannot be changed after CA certificate generation.

% Please enter a passphrase to protect the private key

% or type Return to exit

Password:

Re-enter password:

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

% Exporting Certificate Server signing certificate and keys...

Result config:

crypto pki server R1-root

 issuer-name cn=R1

 grant auto

hash sha256

!

crypto pki trustpoint R1-root

 revocation-check crl

 rsakeypair R1-root

crypto pki certificate chain R1-root

 certificate ca 01

  308201F3 3082015C A0030201 02020101 300D0609 2A864886 F70D0101 0B050030

<output omitted>

Our very, very basic root CA is now running. Note that a trustpoint is created. This trustpoint contains the public/private key pair of the root CA.

As you will see, a root certificate and RSA keys are generated, but with some default settings. Of course, you can customize this, but you need to make all these decisions beforehand.

Now we will set up a trustpoint on our client router. A trustpoint may be seen as a configuration anchor for certificates. If a new certificate chain is configured, you will make a new trustpoint. It’s as simple as that.

 

R2 trustpoint configuration:

R2(config)#crypto pki trustpoint R2

R2(ca-trustpoint)#subject-name cn=R2

Again, a basic name

R2(ca-trustpoint)#enrollment terminal

We will do a manual enrollment, for clarity

R2(ca-trustpoint)#hash sha256

Again, sha256 hash.

R2(ca-trustpoint)#exi

Since this is the most basic configuration, we will not do more than this.

We need to give the public key of R1 to R2. This is needed because R2 needs to be sure the certificate received from R1, truly is from R1.

R1(config)#crypto pki export R1-root pem terminal

% The specified trustpoint is not enrolled (R1-root).

% Only export the CA certificate in PEM format.

% CA certificate:

-----BEGIN CERTIFICATE-----

MIIB8zCCAVygAwIBAgIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJSMTAe

<output omitted for clarity>

-----END CERTIFICATE-----

Now, we will import the CA certificate on R2.

R2(config)#crypto pki authenticate R2

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

MIIB8zCCAVygAwIBAgIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJSMTAe

<output omitted for clarity>

-----END CERTIFICATE-----

Certificate has the following attributes:

Certificate has the following attributes:

       Fingerprint MD5: 261B0F52 062F0310 B1459331 D287142C

      Fingerprint SHA1: 601F179A 158A2F4B EEDA6CC1 19368902 19B71B29

% Do you accept this certificate? [yes/no]: yes

Trustpoint CA certificate accepted.

% Certificate successfully imported

Now, we will create the certificate for R2:

R2(config)#crypto pki enroll R2

% Start certificate enrollment ..

% The subject name in the certificate will include: cn=R2

% The subject name in the certificate will include: R2

% Include the router serial number in the subject name? [yes/no]: no

Jan  5 12:26:43.311: %CRYPTO-6-AUTOGEN: Generated new 512 bit key pair

Since we did not specify the key length, the router assumes the default, 512 bit..

% Include an IP address in the subject name? [no]: no

Display Certificate Request to terminal? [yes/no]: yes

Certificate Request follows:

MIH7MIGmAgEAMCAxCzAJBgNVBAMTAlIyMREwDwYJKoZIhvcNAQkCFgJSMjBcMA0G

<output omitted for clarity>

---End - This line not part of the certificate request---

Now, on R1 we will request and receive the certificate:

R1#crypto pki server R1-root request pkcs10 terminal

% Enter Base64 encoded or PEM formatted PKCS10 enrollment request.

% End with a blank line or "quit" on a line by itself.

MIH7MIGmAgEAMCAxCzAJBgNVBAMTAlIyMREwDwYJKoZIhvcNAQkCFgJSMjBcMA0G

<output omitted for clarity>

% Granted certificate:

MIIBsTCCARqgAwIBAgIBAjANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJSMTAe

<output omitted for clarity>

Here comes the more tricky part. We will import the granted certificate on the trustpoint on R2:

R2(config)#crypto pki import R2 certificate

Enter the base 64 encoded certificate.

End with a blank line or the word "quit" on a line by itself

MIIBsTCCARqgAwIBAgIBAjANBgkqhkiG9w0BAQQFADANMQswCQYDVQQDEwJSMTAe

<output omitted for clarity>

% Router Certificate successfully imported

This completes the certificate configuration of the R2 router. Now we will tell the R2 HTTPS server that it must use the trustpoint:

R2(config)#ip http secure-trustpoint R2

We will now open the webpage in the Firefox browser:

We’ve solved the first two errors, but received a new issue. As Firefox does not have the R1 root certificate and public key, it implicitly does not trust R2’s certificate (as it is signed by R1). In order to solve this, we need to import R1’s certificate into the trusted root store, containing R1’s signature and public key. 

Note the ‘issued by’ field.

Remember the certificate export on R1? We will re-use this information on our Client PC with Firefox browser.

Copy the

 -----BEGIN CERTIFICATE-----

MIIB8zCCAVygAwIBAgIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJSMTAe

-----END CERTIFICATE-----

Information to a basic text editor (IE: notepad), and save it as a .cer file and import it into the Firefox (root) authorities certificate store.

Now the certificate chain is complete. We will receive another error, though:

This is because we have entered https://<ip address>  instead of https://<host name>, as the certificate was made for R2.

Of course, this can be solved to adding R2 to your local DNS or host file.

After adding R2 to the local hostfile, the browser finally continues without errors.