understanding cisco ASA IPSEC site to site tunnel auth using certificates

[west33637]

assuming my company and another company (BBT) are trying to set up a site to site tunnel using certificates. lets say we both have asa 5520s and have agreed to use entrust as our CA.

On my end, I do the certificate enrollment using SCEP and lets assume the BBT end is configured the exact same way.

First, I generate an RSA key pair --- Im assuming this is my ASA's public and private key for encryption and decryption --- (pls correct me if Im wrong)

Next, I configure a trustpoint for certificate enrollment (in this case it'll be Entrust's CA server). I will configure my fqdn and any CRL parameters.

Then, I will obtain a CA certificate from the CA. This contains a fingerprint of the Certificate that is loaded on my ASA. apparently -  the fingerprint in the certificate is used by the 'end entity' to authenticate the received CA certificate. Why would the end entity want to authenticate a CA certificate that has already been installed on it???
In other words, what does this fingerprint really do? surely this cant be the same fingerprint thats gets installed on the BBT ASA?

Finally, I request and install an identity certificate. This requests a password? I believe this is used in case I want to make any changes to the certificate, like revoking the certificate. (Again, please correct me if Im wrong)

a few more questions

during isakmp authentication phase how does my asa verify that the certificate that the BBT ASA sent was indeed signed by the CA that it trusts. How exactly?

Does my ASA and the BBT ASA have to trust the same CA. In other words, do we have to configure the same trustpoints?
or can I have entrust's CA server as a trustpoint and they have verisign?

how does the certificate authentication process work from the time the ASA receives interesting traffic through to encrypted data exchange?

Thanks a million!

[Panos Kampanakis]

Please ask this question in the VPN forum.

PK

[west33637]

hello all. just moved this question to the VPN forum. Thanks,

[Marcin Latosiewicz]

First of all I think some of your questions might require you to go back and do a bit more reading on PKI and RSA :-)

Normally this is tought in class at universities and you can find excelent metarials from universities all around the world.

In general what you need to do is (typical scenario)

On all systems (including CA)

- Setup correct time (NTP highly recommended)

- config hostname and domain name.

- generate RSA keys. private and public they will be used to encrypt/sign certificates.

On ASA/IOS device you wish to enroll:

- configured trustpoint with what-need-you (crl, enrollemtn method etc etc).

- you authenticate a trustpoint by introducing CA who issues your certificate.

- you then generate CSR or enroll via SCEP.

- You download/import certificate from CA. It is signed by public key of CA.

Your certification is normally two parts - your identity certificate, trusted third party certificate who issued you your certificate.

It all boils down to who you trust, if you want one side to use entrust and other to use verisign, you need to have appropriate CA authenticated in you device.

Now all modern operatin system provide you will a list of well known trusted third parties in your certificate store. Which is why when you as user going to "my_internet_bank.com" don't need to trust anything.

This is not the case on ASA or IOS, there is no default list of trusted third parties, all has to be done manually.

Marcin

[west33637]

Hello Marcin. I have actually been doing quite a lot of reading on this subject. Some things were just not that clear and I was throwing questions out there to see if I could get some clarification on some of my specific questions. You did not address my specific questions, but rather walked me through procedures of setting up this authentication. If you paid attention to my question you'll realize that I had already gone through the procedures that you lined up in your answer, but I was trying to get a more profound understanding of exactly how it worked. My questions were more specific. I thought this was the point behind this forum was to get support. If I had all the answers whats the use of having a forum?

[Marcin Latosiewicz]

I think you misunderstood my intention.

What I meant is that people spend whole classes teaching/learning about PKI, a forums is most likely not the place to fill you in on ALL the details, I was just encouraging further reading.

I made a few point on which I didn't think you were very clear in an effort to put some reference.

You can see how much Craig wrote below and I would still call it only an intro with a lot of thing to fill in (even though he makes excelt point at answering your specific questions).

So Craig was giving you the answers while I was hoping (maybe not in a very clear way) to encourage further reading ;-)

If you're interested we can cook up a document describing all the gory details of PKI enrollment + how it's used in authentication process.

But it maybe too much vendor specific at parts. Different vendors might implement same things differently.

Hope this clears the situation ;-)

Marcin

[west33637]

yes it does. thanks! I will continue to read up on this subject. any very good book suggestions would be much appreciated too.

[Craig Lorentzen · Accepted solution]

Hello west33637,

You may want to review this document for an easy example of setting up a S2S VPN using certificates on an ASA

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080aa5be1.shtml

Let me try and break apart your questions and see if I can answer it.  I am going to speak without using SCEP as it adds a layer of complexity which may be causing confusion.

Q) How does one get a certificate?

1. Generate an RSA Keypair.  An RSA Keypair as you indicate has a public and private key.  The public and private keys are large number created by multiplying other large prime numbers (very simple explanation).  These keys are used for control plain encryption.  The private key is kept privately and never given out.  The public key is provided to everyone via the certificate received from the device.

Data encrypted by the public key can only be decrypted by the private key, and vice versa.

more details here: http://en.wikipedia.org/wiki/RSA

2. We create a trustpoint (container to configure and define parameters around the certificate).  In the trustpoint we associate the RSA Keypair, give a name (usually the FQDN of the server who will be presenting this certificate), configure if certificates which are authenticated by the trustpoint should also be checked against the CRL...etc.

3. Next we can create the CSR by using the crypto ca enroll command.  Now we take this CSR and provide it to Entrust.  If this were done via SCEP you would have already done the next step of authenticating the trustpoint.

4. When you receive a certificate from a third party, like Entrust, they should also provide you the certificate chain which provides authentication of the certificate which they signed all the way back up to the root (self-signed certificate server, this certificate should already be trusted by most OSes/web-browsers).  We will want to install the chain in the ASA since the ASA does not trust any certificate by default, it has an empty certificate store.

5. On the ASA we now install the chain provided by Entrust.  Generally your identity certificate will be signed by an intermediate certificate authority, just like the supportforums.cisco.com certificate.  The ASA trustpoint system allows for one CA (Root or Intermediate) and one ID (identity) per trustpoint.  So we will likely need at least one more trustpoint.

  crypto ca trustpoint Entrust_ROOT

    enrollment terminal

    exit

  crypto ca trustpoint authenticate Entrust_ROOT

Remember to use trustpoint names which have significants to you and your organization.  Create a trustpoint for each of the CA certificates except for the direct signer of your ID certificate.  Authenticate the direct signer into the same trustpoint where you install your ID certificate.

crypto ca trustpoint import ID certificate.

You should now have a fully authenticated certificate which can be used.  importing from PKCS12 would require a certificate to decrypt the private key which is stored in a PKCS12.  But if you are generating your CSR on the same device as where you are installing the certificate then there would be no need to export to PKCS12 and have a password.

---

A little side not on signing, a certificate signature (thumbprint) also known as a digitial signature, is a hash of the certificate encrypted with the private key of the signer.  As we know, anything encrypted with a private key can only be decrypted by the public key...everyone who trusts the signer has the public key.  So when you receive the certificate, and you already trust the signer you can then 1) decrypt the signature and 2) check that your hash of the certificate matches that decrypted hash...if the decrypted hash doesn't match then you don't trust the certificate.

For an example you can look at the certificate for supportforums.cisco.com,

The subject is: CN = supportforums.cisco.com

The issuer (signer) subject is CN = Akamai Subordinate CA 3

Akamai Subordinate CA 3 is an intermediate certificate authority.  It is not self-signed

The issuer of CN = Akamai Subordinate CA 3 is CN = GTE CyberTrust Global Root

CN = GTE CyberTrust Global Root is a Root certificate (self-signed).

We would want to install this entire chain in the ASA so that we can safely provide out this certificate and chain to any device and as long as that device trusts CN = GTE CyberTrust Global Root then it should be able to check the signatures of the intermediate and finally our identity certificate to trust us.

---

Look for another post to do a quick discussion of how the certificate is used within ISAKMP and IPSec.

Regards,
Craig

[Craig Lorentzen]

Q. How are certificates used in the ISAKMP and IPSec process?

Understand that the Certificate is not used to encrypt the actual data, it is only used at the control plan.  RSA keys are used, along with certificates, to provide a "pre-shared" key without having to manually provide it.

So in IPSec we only use the certificate during Phase 1 (ISAKMP) and it is used in the hashing mechanism to authenticate each other.  We provide our certificate to the remote host, this gets them the public key.  The other side validates the certificate by using the digital signature (discussed in my last post), if we trust the certificate then we trust the public key and can use it to decrypt the ISKMP hash and confirm the authenticity of the remote side.  If that hash doesn't match then we assume that the remote device does not own the private key which matches the public key received in the certificate and we cannot trust them.

Everything else is the same, DH Keying material is provided as normal and is used to create the shared key which is used in a symetric encryption algorithm that you define for the crypto map (the transform-set).

I think that my two posts should have answered your questions fully, please let us know if one of your questions was not answered so that we can help.

As per Marcin reading up on PKI should also help provide the same information I wrote above.

-Craig