Cisco ASA and Microsoft Enterprise CA

I’m sure most of you guys had opportunity to set up an IPSec VPN tunnel between two (Cisco) devices. I’m also almost certain that most of the time you used pre-shared keys for authentication. The reason for this is simple: it’s easy to set up. There is no need for diving into rather complex matter of setting up a “PKI infrastructure”. Fair enough. Me myself was having issues in setting up this infrastructure, not because it’s hard to comprehend but because there is very little documentation on this. Hold on a sec, you will say, there is tons of books on this subject. Well, yes and no. I’m doing this PKI thing for years now and yes, there is tons of papers. But no, there are almost none that solves your specific problem. Mine was integrating Cisco ASA firewall, VPN Client and Microsoft Enterprise CA.

Doing certificate based authentication between network devices requires several steps:

  1. Setting up PKI infrastructure which will be used for requesting, issuing and revoking certificates as well as maintaining CRL
  2. Creating CSR on network device
  3. Sending this CSR to the CA
  4. Issuing certificate which is done by the CA
  5. Installing the certificate on the device
  6. Setting device(s) for RSA authentication using granted cert

I won’t  be dealing with setting the PKI right now. It is so huge topic that would take me eons to bring it to you. For now let’s say that this can be done in many ways with many vendors. If you will be doing this on Cisco IOS (please don’t 🙂 ) you may start my reading this. Why not Cisco? I will try to put it this way: cars are made for driving not sailing. Although you can (I guess) take your car to some geek mechanic  to make a boat out of it, it’s better to buy a boat in a first place. How this remark fits in the Cisco world? Those guys are the best in some arenas, like switching and routing and perhaps security.  They make awesome products, but those products are cars, not boats. There are companies that are best in making boats, not cars. You got the picture here? Good, let us continue with technology, not philosophy.  I would recommend Microsoft for PKI. Their PKI solution implements all PKI stuff and you get it for free!  If you agree with me, you may start by reading this.

We can request and install certs two ways. Let’s call first way the terminal way.  This name comes from the fact that the CSR is displayed on the console terminal, saved to a file and sent to CA. When CA issues the cert it is again displayed or pasted on the terminal. The second way we will call a SCEP or NDES way. What is SCEP?  According to Wikipedia, SCEP (Simple Certificate Enrollment Protocol) is designed to make the issuing and revocation of digital certificates as scalable as possible.  This means that lot’s of things are made automatic and thus easier. NDES is what Microsoft calls SCEP in Windows 2008 server. The protocol is more or less the same but the implementation is a little bit different. I will deal with NDES more in up coming article, so stay tuned.

Creating CSR on Cisco router or firewall is very similar. I will focus on firewall this time.

Before we generate CSR, we should do some homework:

  • We should make sure that time is accurate across the whole enterprise or at least across all devices that will be included in the PKI. This is because PKI relies heavily on correct time. I strongly suggest that you use Network Time Protocol or NTP for this
  • Because we have to generate RSA key pair and this key pair needs host name and domain name, we must set up those two
  • We generate RSA key pair. It comprises of two keys: private key which is held on the device itself and the public key, which will be a part of issued certificate

Let’s begin our configuration with the last step, because first two are trivial. We generate RSA key pair like this:

cry key gen rsa gen label POPRAVAK mod 2048

What this command means is that this device will generate RSA key pair which will be called POPRAVAK, has general purpose and key length of 2048 bits. Now we have keys. It is time to create a trust point. A trust point is a way of telling the firewall how to deal with certificates: how to request them, verify them or installing them. A trust point could be thought of as a glue between key pair, certificate and CA. There is a catch here: some times you will be using just one trust point but there will be times when you will need more, most often just two. It depends on what? You may have one CA that is issuing only 1024bit key length certs and you may find that this suffice for your internal usage of for plain old IPSec VPN. Then, you may need another one for SSL VPN or TLS/SSL connections with 2048bit key lengths.  Or, such as in our case, we have two-tier PKI infrastructure with an offline root CA and an online issuing CA. In such case you need one trust point for offline root CA (see terminal way above) and one trust point for online issuing CA (see NDES way). Ok, let’s create them both now:

crypto ca trustpoint POPRAVAK-ROOT
 enrollment terminal
 keypair POPRAVAK
 crl configure  
 
 

crypto ca trustpoint POPRAVAK-SUB
 enrollment url http://ndes:80/certsrv/mscep/mscep.dll
 subject-name CN=asa-pop.popravak.com,OU=IT,L=Bijeljina,ST=RS,O=Popravak Ltd,C=BA
 keypair POPRAVAK
 crl configure

A brief description of both. First set of commands create one trust point for root CA. Requesting and issuing method is terminal because we don’t actually have a choice here. This is because in proper PKI set up root CA server is always kept offline, or powered off or even it has its disks removed in the safe far-far away. This is normal and is a security measure. We ere using previously generated key pair.

Second trust point is more interesting. It creates second level CA, also called subordinate CA. This level in PKI hierarchy is always online and is issuing certificates (there could be more levels and this level could be also offline, but those are pretty large set ups and the way of functioning is almost the same). This time we are using SCEP or NDES for handling certificate operations. “ndes” is the name of the server and for this to work you must have it defined under the names section of firewall or must have DNS set up on the firewall. The rest is just the path to the IIS extension running on this server that implements the SCEP/NDES protocol.  Subject name is X509 name format with basic fields listed. We are also using the same key pair because this is the same PKI hierarchy.

Before we go on I would like to talk a little bit about this NDES server. This server is NOT the server that runs PKI! Other servers are responsible for this. In Microsoft’s implementation PKI is running on CA servers which go hand in hand with DCs (domain controllers). So, why would we need this NDES server? Because before CA server issues any certs it must authenticate all PKI clients requesting certificates and verify they are in titled to requesting certificates from this CA. They do so by talking to DCs. Ok, but still, why NDES server? Because we don’t have Cisco routers’ or firewalls’ accounts in AD (Active Directory) infrastructure and they cannot be authenticated and authorized as such. So we need this NDES server that is a part of AD and is going to authenticate/authorize our devices on their behalf.

The next step is authenticating to the CA. This process actually gets and installs the CA certificate.  We need this cert to be able to verify digital signature of all certs issued by this CA. This is because CA signs issued certs with its private key and CA cert, which we receive by authenticating, contains public key needed for digital signature verification. So, let’s authenticate.

cry ca auth POPRAVAK-ROOT

Remember that the POPRAVAK-ROOT trust point is of type “terminal”. So we need to obtain root CA somehow in the BASE-64 format and paste it in the terminal and after that hit <ENTER>, type the word “quit” and hit <ENTER> again. Just follow the messages on the console. The CA cert should look like this:

-----BEGIN CERTIFICATE-----
MIIDZTCCAk2gAwIBAgIQcqu+7p3aQItBAxoHA+fi4jANBgkqhkiG9w0BAQUFADBF
...... lots of lines like these omitted……………
+1MXecJW0TVigIDTEvvrQOZPZgV5S5IXRjXhji/fUxdRhpwI2EvWrvx2AbgT/M69
7rrutc265qr0
-----END CERTIFICATE-----

Ok, now we have offline root CA installed. Next we need subordinate CA certificate as well.

cry ca auth POPRAVAK-SUB
 

This time we don’t need to do any manual work. If all is ok, we will get subordinate CA certificate via network and the message “Certificate validated – Signed by existing trustpoint CA certificate.” should come up to confirm that we successfully built a certificate chain.

Now let’s verify our CA certs:

ASA-POP# show cry ca cert
CA Certificate
  Status: Available
  Certificate Serial Number: 617ebb7b000000000002
  Certificate Usage: Signature
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA1 with RSA Encryption
  Issuer Name:
    cn=Popravak Ltd Root CA
    o=Popravak Ltd
    c=BA
  Subject Name:
    cn=Popravak Ltd Issuing CA
    o=Popravak Ltd
    c=BA
  CRL Distribution Points:
    [1]  ldap:///CN=Popravak%20Ltd%20Root%20CA,CN=NBROOTCA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=popravak,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    [2]  http://crl.popravak.com/Certdata/Popravak%20Ltd%20Root%20CA.crl
  Validity Date:
    start date: 12:50:08 CET Apr 20 2011
    end   date: 13:00:08 CET Apr 20 2021
  Associated Trustpoints: POPRAVAK-SUB

CA Certificate
  Status: Available
  Certificate Serial Number: 72abbeee9dda408b41031a0703e7e2e2
  Certificate Usage: Signature
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA1 with RSA Encryption
  Issuer Name:
    cn=Popravak Ltd Root CA
    o=Popravak Ltd
    c=BA
  Subject Name:
    cn=Popravak Ltd Root CA
    o=Popravak Ltd
    c=BA
  Validity Date:
    start date: 12:17:10 CET Apr 20 2011
    end   date: 12:27:09 CET Apr 20 2031
  Associated Trustpoints:POPRAVAK-ROOT

You can see that we have valid root and subordinate CA certificates.  Now it’s time to request and install so called identity certificate which represents the firewall itself, not the CA. In order for this to work, firt we must visit this web page from one of PCs in our AD domain:

http://ndes/certsrv/mscep_admin/

This should be visited with Internet Explorer. If NDES is set up according to best practices a log in form will pop up which requires us to log on. This is because NDES should be set up in such a way that is using dedicated AD user account with the privileges of requesting certs on behalf of network devices. Because we are using our regular account which does not have needed rights, we need to provide the right credentials. Fill in the user name in the form of “POPRAVAK\NDES.Device” or “NDES.Device@popravak.com” and appropriate password. If NDES is set up as should be we should get this enrollment password screen:

This password is valid for sixty minutes and is randomly generated for each session. If a network device later supplies this same password within the sixty minutes time range then that device is considered as authenticated.

So let’s hurry up, because the time is running out. We now need to request the identity certificate using this password:

ASA-POP(config)#
ASA-POP(config)# cry ca enroll POPRAVAK-SUB
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.
Password: **************** (this is actually 76377E9D97A59D20, the pass from above)
Re-enter password: ****************(this is actually 76377E9D97A59D20)
 
% The subject name in the certificate will be: CN=asa-pop.popravak.com,OU=IT,L=Bijeljina,ST=RS,O=Popravak Ltd,C=BA
 
% The fully-qualified domain name in the certificate will be: ASA-POP.popravak.com
 
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
ASA-POP(config)#

If we receive this error:

The certificate enrollment request was denied by CA!

we need to go back and double check everything on ASA and PKI.

Hopefully, we will see:

The certificate has been granted by CA!

If so, we can go on with this article.

This is what the identity cert looks like:

ASA-POP# show cry ca cert
Certificate
  Status: Available
  Certificate Serial Number: 61a66bea000000000033
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA1 with RSA Encryption
  Issuer Name:
    cn=Popravak Ltd Issuing CA
    o=Popravak Ltd
    c=BA
  Subject Name:
    cn=asa-pop.popravak.com
    ou=IT
    o=Popravak Ltd
    l=Bijeljina
    st=RS
    c=BA
    hostname=ASA-POP.popravak.com
  CRL Distribution Points:
    [1]  ldap:///CN=Popravak%20Ltd%20Issuing%20CA,CN=NBISSCA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=popravak,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
    [2]  http://crl.popravak.com/Certdata/Popravak%20Ltd%20Issuing%20CA.crl
    [3]  http://nbissca01.popravak.com/CertEnroll/Popravak%20Ltd%20Issuing%20CA.crl
  Validity Date:
    start date: 09:09:06 CET Aug 11 2011
    end   date: 09:09:06 CET Aug 10 2013
  Associated Trustpoints: POPRAVAK-SUB
 

If you open this certificate in Windows, this is how it looks like:

You can see that this cert is issued for device asa-pop.popravak.com and is issued by subordinate CA “Popravak Ltd Issuing CA” which is in turn issued by root CA “Popravak Ltd Root CA”. You can also see that this certificate is considered valid. Please ignore red lines: I’m using my corporate network for writing this article and I don’t want to use real names 🙂

Now use “wr m” to save your work because we are done for today. Next time I’m going to write about setting this ASA firewall for remote access VPN and use Cisco VPN client and client side certificate on it to actually make a VPN connection.

So until the next time …

Advertisements
This entry was posted in ASA, Certificates, Cisco, Microsoft, PKI and tagged , , , , , , , . Bookmark the permalink.

5 Responses to Cisco ASA and Microsoft Enterprise CA

  1. I don’t even know how I ended up here, but I thought this post was great. I don’t know
    who you are but certainly you’re going to a famous blogger if you are not already 😉 Cheers!

  2. durd84David says:

    Odd, i just set up s2s ipsec between two ASAs with certificates from MS CA and only needed our Intermediate Certificate and not the root-certificate. Although i guess our intermediate could be called a root cert as that is how its being used…
    I encountered two problems, the first was using different trustpoints for the Identity cert and the CA cert (asdm wanted it so), it needed to be the same trustpoint for both. The second problem was to issue a cert with the correct usage. That done we had a tunnel with traffic flowing both ways.

  3. loc Nguyen says:

    it is a great article. Thank you

  4. Ronie says:

    I have a difficult in setting up the EKU application policies in newly created certificate template. May I know what application policies (client authentication, server authentication, ike usage.. ) need to be included in certificate template going to be issued via SCEP ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s