cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
909
Views
0
Helpful
4
Replies

question about CA enrollment

west33637
Level 1
Level 1

I have a hub and spoke company wide site to site dmvpn. we are currently using psk for IKE authentication. we are looking to change to an internal PKI infrastructure for IKE authentication. I have configured an internal root CA and 2 sub-CAs on 1941 routers for this purpose. We plan to use SCEP auto-enrollment for the Headend and spoke routers to enroll to these internal CAs. My question is which of these CAs should I have my routers enroll to? Or can I have some routers enroll to sub-CA1 and some enroll to sub-CA2 and maybe a couple to root-CA?

enrollment url http://rootCA:80

enrollment url http://subCA1:80

enrollment url http://subCA2:80

???


1 Accepted Solution

Accepted Solutions

Hi,

There is no problem from IPsec's perspective to be enrolled to both subCAs.

The CERT_REQ payload will be sent for both of subCAs in Main Mode message 3 and 4.

(note: if you want to tweak this behavior you can select particular trustpoint withing isakmp profile)

Nowayds it's rather more important to make the CRL highly available than the CA (or subCA) itself.

Having two subCAs means not relying on single hardware to provide enrollment/CRL update functions.

Note that you can chain certificates up to root, which essentially should enable spokes enrolled to subCA1 to establish IPsec with subCA2.

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_auth_rev_cert_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1065596

I have not attempted to do this with SCEP ... so not sure if you can do it with automated way ...

Marcin

View solution in original post

4 Replies 4

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Hi,

Did you get already an answer on this one?

In practice you should enroll to subCAs only and if need provide a certificate chain all the way to the root.

How this usually implemented in few setups I saw is to have multiple DMVPN clouds, 1 using subCA1 the other using subCA2 for IKE - in this setup if one subCA would go down the other would still work and DMVPN would still work.

It's of course a question of your design and what you would like to achieve.

Also please remember that although most of routers need only access to CRL to establish IPsec VPN, some IOS versions also perform SCEP capability check on CA when establishing IKE session.

HTH,

Marcin

Hello Marcin. Thanks for the response. We are currently running a single cloud dual headend DMVPN. We are planning to move to a dual cloud dual headend approach with our headends geographically spread out. The spokes will have 2 tunnels and one will be preferred using cost.

As I mentioned earlier, I set up a root CA and 2 sub-CAs. I had the DMVPN1 headend router download it cert via SCEP from sub-CA1 and the DMVPN2 router from sub-CA2. I then had one of my spoke routers download it cert from sub-CA1. My spoke (enrolled to sub-CA1) was able to authenticate to the DMVPN1 headend router that was also enrolled to sub-CA1, but not to the DMVPN2 headend that is enrolled to sub-CA2.  When I checked the 2 DMVPN hub routers CA certs, the DMVPN1 router received a CA cert from the sub-CA1, while the DMVPN2 router received a CA cert from the sub-CA2.

sub-CA2 cannot decrypt the certs issued by sub-CA1. if this is so, whats the point of having sub-CAs? or am I doing something wrong.

Is there a way to make the sub-CAs download their entire cert chain to the DMVPN clients? That way all clients will have the root cert and would be able to authenticate regardless of which sub-CA they got their cert from.

Alternatively, can I just enroll all the DMVPN routers to both sub-CAs?

Thanks

Hi,

There is no problem from IPsec's perspective to be enrolled to both subCAs.

The CERT_REQ payload will be sent for both of subCAs in Main Mode message 3 and 4.

(note: if you want to tweak this behavior you can select particular trustpoint withing isakmp profile)

Nowayds it's rather more important to make the CRL highly available than the CA (or subCA) itself.

Having two subCAs means not relying on single hardware to provide enrollment/CRL update functions.

Note that you can chain certificates up to root, which essentially should enable spokes enrolled to subCA1 to establish IPsec with subCA2.

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_auth_rev_cert_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1065596

I have not attempted to do this with SCEP ... so not sure if you can do it with automated way ...

Marcin

thanks a lot for this response. That document was very insightful.