Cisco ASA Site-to-Site IPsec VPN Digital Certificates

This topic is to discuss the following lesson:

Rene,
Well done with this post, please post more article with this kind.
Thank you

Rene,
Thanks for the presentation, great info as always…

What would be the advantages of changing my current ASA VPN Pre-Shared Keys to Certificates?

I am kind of new to certificates, so what would be the process for my customers who connect with PSK VPNs? Would they need to provide me certificate from a trusted CA for my ASA, and I would provide them a certificate as well?

If i have a couple hundred VPNs, can i provide the same certificate to every customer, or is that not a best practice?

Thanks again for all the great tutorials.

Hi Brian,

Security-wise, the public/private key of a certificate are typically longer than a pre-shared key.

If you want to use certificates then both devices will have to trust the same root CA. You could use your own CA like I did with this example and sign two certificates. One for your firewall and one for the customer. Since both devices trust the CA, they will trust each other’s certificate.

This is the main advantage of using certificates. For example, let’s say you have 100 customers that build a VPN to your main office’s firewall. If you want to add an extra firewall that the customers could connect to then you have to configure 100 pre-shared keys for all 100 customers so connect to the second firewall. You could use the same pre-shared key everywhere but that means once the key is compromised, you have to replace it everywhere…not a good idea!

When you use certificates, you only have to add a new certificate to the second firewall. Since the customers trust the CA, they will trust the certificate of the second firewall automatically.

You could use the same certificate, it’s even possible to use a “wildcard” certificate but that’s not a good idea. It’s the same as using the same pre-shared key everywhere. Once the key (or certificate) is compromised, you’ll have to replace it. Replacing a key/certificate on 2 devices is no problem but for 100 devices it might be a pain :slight_smile:

It might be helpful to see this in action. You can use my example to build a CA with OpenSSL and then use 2-3 firewalls to build a VPN that uses the certificates.

Hope this helps!

Rene

HI my friend.

I am not sure if CA must be always available to the peers even when they authenticate each other. At the moment CA is not available the vpn will failed? what happen if reload one of the peers? it was only available at the moment of enrolling and authenticating certificates, could you explain me please?

Can you provide more details on the significance of the hostname on the device and in the CSR/cert? Does the cert hostname need to always match the ASA assigned hostname? Do either of those hostnames need to match a forward or reverse DNS name registered for the device?

Hello Brian

The use of a hostname is essentially there to make your life easier. According to Cisco: “Assigning a hostname identifies the host for subsequent enrollment commands, additional configuration, and provides flexibility in case the IP address of the CA server changes.”

Yes. If you change ASA hostname it will invalidate your current certificates and you’ll need to regenerate them after the name change. If you have end devices or a site-to-site VPN that relies on certificates, those connections will fail until you regenerate and re-establish the connection.

No. The names are locally significant as far as the creation of certificates is concerned.

I hope this has been helpful!

Laz

How to modify this process for Certificates + IKEv2 ?

Is it as simple as replacing “ikev1” with “ikev2” in the steps?

It is pretty much the same yes, here’s an example for IKEv2 site-to-site. I used pre-shared keys in that example but changing it to use certificates shouldn’t be an issue:

This command is fix or use anythigs like (e,can,o)
Subject Name:
e=admin@networklessons.local
cn=CA.networklessons.local
o=Networklessons
l=Tilburg
st=North-Brabant
c=NL

Hello Ram

You are able to use many different attributes in this command. All of the available attributes can be found at this Cisco documentation PDF, on page 22:

I hope this has been helpful!

Laz

Thanks for help…

nice job team

1 Like

Good day to you all!

I have a simple question. Is there any reason why we not using IKEv2 in this scenario?

Hello András

The purpose of this particular lesson is to show how certificates function. Rene could have used IKEv2 as well, but that would not make a difference as far as the certificate mechanisms go. One of the two had to be chosen, and he chose IKEv1. Also, if you look at the list of lessons in this unit, the lessons before this one cover IKEv1 only, IKEv2 is covered in subsequent lessons, so if you’re following the lessons sequentially, at this point IKEv2 has not yet been covered.

Attempting to perform this lab using IKEv2 is a good opportunity to get some lab experience in there as well…

I hope this has been helpful!

Laz

1 Like

Their is one more question from site-to-site IPSEC VPN with Digital certificate ?

ASA1(config-ca-trustpoint)# fqdn ASA1.networklessons.local

And the attributes that identify our device:

ASA1(config-ca-trustpoint)# subject-name O=Networklessons, C=NL, EA=admin@networklessons.local, ST=North-Brabant, CN=ASA1.networklessons.local

The FDQN and Attributes name you chosen are predefined or we can give any attribute for any name ?

Hello Pradyumna

The FDQN and attributes are chosen and not predefined. They are the attributes that the specific certificate will use and are defined using these commands.

I hope this has been helpful!

Laz

Hi Rene and staff,
guess i am tired with all the stuff to learn, but i dont understand the logic

First
we had to import the public certificate of the CA (which role is to validate the ASA public certificate)

Second
in ASA produce private key (note: the public is produced as well)
generate CSR with the private key of ASA
send to disconnected CA server which is going to sign the CSR with its private key
import the signed CSR which becomes the ASA public certificate

Third
Match ASA public certificate against root certificate to know if ASA is trusted
If the two ASAs are trusted vpn can be established

So, why are you giving the same name MY_CA to

  • root certificate
  • ASA CSR
  • ASA public certificate

??
I dont understand the logic
Incidentally , you will have a warning because the fqdn in root certificate is ca.networklessons.local
and fqdn in CSR with the same name is
asa1.networklessons.local

Could you clarify ?
Regards

Hi Rene and staff,
my post is not so old, but not so new at the same time.
It seems like no one have trouble with this lesson where MY_CA is the name of the root certificate and also the CSR’s name
So i wonder what i missed ?
regards

Thank you all for these lessons!

I have attempted to combine several of the ASA lessons together, and setup l2l VPNs between a core and two remote “spoke” locations. There is no connectivity between the spokes, only spoke to hub/core. I was able to get things working with ikev2 and certificate authentication, but only with one spoke at a time. The configuration that allowed this required the line:

crypto map MADEUP_NAME_MAP interface outside

With a single remote this worked wonderfully, but with two I needed to combine both MADEUP_NAME_MAP and OTHER_MADEUP_NAME_MAP into a dynamic-map, and doing so caused the entire VPN functionality to stop working.

This is the key parts of the hub/core which allowed this to work for the specified single spoke:

1. access-list MADEUP_NAME extended permit ip object OBJ-HOSTA 192.168.2.0 255.255.255.0 2. access-list MADEUP_NAME extended permit ip object OBJ-HOSTB 192.168.2.0 255.255.255.0 3. crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL 4. protocol esp encryption aes-256 5. protocol esp integrity sha-512 sha-384 sha-256 sha-1 6. crypto ipsec security-association pmtu-aging infinite 7. crypto map MADEUP_NAME_MAP 11 match address MADEUP_NAME 8. crypto map MADEUP_NAME_MAP 11 set peer 2.2.2.2 9. crypto map MADEUP_NAME_MAP 11 set ikev2 ipsec-proposal MY_PROPOSAL 10. crypto map MADEUP_NAME_MAP interface outside 11. crypto ca trustpoint MY_CA 12. enrollment terminal 13. fqdn sub1.company.com 14. subject-name O=Company, C=US, EA=support@company.com, ST=New-York, CN=sub1.company.com 15. serial-number 16. keypair sub1.company.com_csr 17. crl configure 18. crypto ca trustpool policy 19. auto-import 20. crypto ikev2 policy 11 21. encryption aes-256 22. integrity sha512 23. group 21 24. prf sha 25. lifetime seconds 86400 26. crypto ikev2 enable outside

When I tried to change the map to a dynamic-map to include both spokes at once, this is what I did:

1. "crypto dynamic-map MADEUP_NAME_MAP 10 match address MADEUP_NAME" 2. "crypto dynamic-map MADEUP_NAME_MAP 10 set peer 2.2.2.2" 3. "crypto dynamic-map MADEUP_NAME_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL" 4. "crypto dynamic-map OTHER_MADEUP_NAME_MAP 10 match address OTHER_MADEUP_NAME" 5. "crypto dynamic-map OTHER_MADEUP_NAME_MAP 10 set peer 3.3.3.3" 6. "crypto dynamic-map OTHER_MADEUP_NAME_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL" 7. "crypto map MY_CRYPTO_MAP 10 ipsec-isakmp dynamic MADEUP_NAME_MAP" 8. "crypto map MY_CRYPTO_MAP 20 ipsec-isakmp dynamic OTHER_MADEUP_NAME_MAP" 9. "crypto map MY_CRYPTO_MAP interface outside"

At this point, both the hub and both spokes are able to ping one another so simple connectivity is established, but show crypto isakmp sa or show crypto ikev2 sa shows no connections at all. Does anyone see what I did incorrectly when converting my static maps to dynamic maps?

Sorry I couldn’t get either the code, pre-formatted text, or quotes to display my configs clearly, one line of code per line. Unsure what is going on there. I hope it is readable!

Hello James

Thanks for the detailed post! In order to make this work, keep the following in mind:

The difference between site-to-site and hub-and-spoke is that you need to add some extra commands:

  • Static routes
  • Access-list entries
  • Crypto map change on ASA1.

Also you must add one new command on ASA1:

same-security-traffic permit intra-interface

This permits the ASA to receive and transmit packets out of the same interface (OUTSIDE).

@ReneMolenaar has gone to the trouble of labbing this one up and he has come up with the following full configs:

ASA1

hostname ASA1
!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.1.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 192.168.123.1 255.255.255.0 
!
same-security-traffic permit intra-interface
!
access-list ASA1_ASA2 extended permit ip host 192.168.1.1 host 192.168.2.2 
access-list ASA1_ASA2 extended permit ip host 192.168.3.3 host 192.168.2.2 
access-list ASA1_ASA3 extended permit ip host 192.168.1.1 host 192.168.3.3 
access-list ASA1_ASA3 extended permit ip host 192.168.2.2 host 192.168.3.3 
!
route OUTSIDE 192.168.2.0 255.255.255.0 192.168.123.2 1
route OUTSIDE 192.168.3.0 255.255.255.0 192.168.123.3 1
!
crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL
 protocol esp encryption aes
 protocol esp integrity sha-256
!
crypto ipsec security-association pmtu-aging infinite
crypto map MY_CRYPTO_MAP 10 match address ASA1_ASA2
crypto map MY_CRYPTO_MAP 10 set peer 192.168.123.2 192.168.123.3 
crypto map MY_CRYPTO_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL
crypto map MY_CRYPTO_MAP 20 match address ASA1_ASA3
crypto map MY_CRYPTO_MAP 20 set peer 192.168.123.3 
crypto map MY_CRYPTO_MAP 20 set ikev2 ipsec-proposal MY_PROPOSAL
crypto map MY_CRYPTO_MAP interface OUTSIDE
!
crypto ikev2 policy 10
 encryption aes
 integrity sha
 group 14
 prf sha
 lifetime seconds 86400
crypto ikev2 enable OUTSIDE
!
tunnel-group 192.168.123.2 type ipsec-l2l
tunnel-group 192.168.123.2 ipsec-attributes
 ikev2 remote-authentication pre-shared-key CISCO
 ikev2 local-authentication pre-shared-key CISCO
tunnel-group 192.168.123.3 type ipsec-l2l
tunnel-group 192.168.123.3 ipsec-attributes
 ikev2 remote-authentication pre-shared-key CISCO
 ikev2 local-authentication pre-shared-key CISCO
!
: end

ASA2

hostname ASA2
!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.2.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 192.168.123.2 255.255.255.0 
!
access-list ASA2_ASA1 extended permit ip host 192.168.2.2 host 192.168.1.1 
access-list ASA2_ASA1 extended permit ip host 192.168.2.2 host 192.168.3.3 
!
route OUTSIDE 192.168.1.0 255.255.255.0 192.168.123.1 1
route OUTSIDE 192.168.3.0 255.255.255.0 192.168.123.1 1
!
crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL
 protocol esp encryption aes
 protocol esp integrity sha-256
!
crypto ipsec security-association pmtu-aging infinite
crypto map MY_CRYPTO_MAP 10 match address ASA2_ASA1
crypto map MY_CRYPTO_MAP 10 set peer 192.168.123.1 
crypto map MY_CRYPTO_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL
crypto map MY_CRYPTO_MAP interface OUTSIDE
!
crypto ikev2 policy 10
 encryption aes
 integrity sha
 group 14
 prf sha
 lifetime seconds 86400
crypto ikev2 enable OUTSIDE
!
tunnel-group 192.168.123.1 type ipsec-l2l
tunnel-group 192.168.123.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key CISCO
 ikev2 local-authentication pre-shared-key CISCO
!
: end

ASA3

hostname ASA3
!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.3.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 192.168.123.3 255.255.255.0 
!
access-list ASA3_ASA1 extended permit ip host 192.168.3.3 host 192.168.1.1 
access-list ASA3_ASA1 extended permit ip host 192.168.3.3 host 192.168.2.2 
!
route OUTSIDE 192.168.1.0 255.255.255.0 192.168.123.1 1
route OUTSIDE 192.168.2.0 255.255.255.0 192.168.123.1 1
!
crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL
 protocol esp encryption aes
 protocol esp integrity sha-256
!
crypto map MY_CRYPTO_MAP 10 match address ASA3_ASA1
crypto map MY_CRYPTO_MAP 10 set peer 192.168.123.1 
crypto map MY_CRYPTO_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL
crypto map MY_CRYPTO_MAP interface OUTSIDE
!
crypto ikev2 policy 10
 encryption aes
 integrity sha
 group 14
 prf sha
 lifetime seconds 86400
crypto ikev2 enable OUTSIDE
!
tunnel-group 192.168.123.1 type ipsec-l2l
tunnel-group 192.168.123.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key CISCO
 ikev2 local-authentication pre-shared-key CISCO
!
: end

Let us know how you get along!

I hope this has been helpful!

Laz

I have solved this. My mistake was thinking that I needed a dynamic-map. A dynamic-map was not needed in this case, as all the spokes of the hub have static IPs. All I needed to do was set things up like so:


1. crypto map MY_CRYPTO_MAP 10 match address MADEUP_NAME
2. crypto map MY_CRYPTO_MAP 10 set peer 2.2.2.2
3. crypto map MY_CRYPTO_MAP 10 set ikev2 ipsec-proposal MY_PROPOSAL
4. crypto map MY_CRYPTO_MAP 20 match address OTHER_MADEUP_NAME
5. crypto map MY_CRYPTO_MAP 20 set peer 3.3.3.3
6. crypto map MY_CRYPTO_MAP 20 set ikev2 ipsec-proposal MY_PROPOSAL
7. crypto map MY_CRYPTO_MAP interface outside