Sunday, 22 September 2013

SRX IPSec VPN - Certificate Authentication

In this post digital certificates will be used to authenticate IPSec VPN tunnels. This exercise builds off of the existing configuration steps completed in the previous posts [SRX IPSec VPN - MultipointSRX IPSec VPN - Multipoint with OSPF, SRX IPSec VPN - Route Based]. Please feel free to reference these for additional IPSec details.

Public Key Infrastructure (PKI) is a set of components which allow you to use and manage digital certificates. We will only focus on a subset of PKI, specifically the components needed to securely authenticate VPN peers.

The diagram below outlines the lab topology.



Configure Certificate/PKI
1. Create CA Profile
The certificate authority (CA) is an entity that can sign digital certificates. The CA is a trusted source and it will contain a chain of trust all the way to a root CA. For the internet a root CA might be Entrust or VeriSign. For the example of this lab I used a Windows 2008R2 server with the role Active Directory Certificate Services running to act as the trusted CA. This CA needs to be configured on the SRX devices, the commands below outline the steps to configure a trusted CA. Keep in mind that in this example I used the server name as the ca-identity, this could also be a domain name/suffix. The screenshots below outline the commands.



2. Set CA Profile Revocation Check
Certificate revocation allows the CA to 'recall' certificates it has already issued. This could be for a number of reasons such as the device is no longer trusted. In the case of this exercise revocation is not used and the commands below outline the steps to disable revocation.



3. Generate Key Pair
In this step each SRX needs to generate a key-pair. In public key cryptography there are two parts, the private key which always remains on the device, and the public key which is sent to communicating parties. Getting into the details of public key crypto is out of the scope of this post. To keep it simple -  if one part of the key encodes (or signs) the other can decode and vice versa. The screenshots below outline the steps to generate key pairs on the SRX devices. Note that this is done from the operational command line interface (CLI).



4. Generate Certificate Request (CSR)
The next step is for the SRX devices to have a certificate signed by the trusted CA. To do this a request must be sent to the CA for processing. In the request device/organizational parameters can be specified, one domain name, email address or IP address must be specified. Optionally you can include subject items. Once processed the CA will return a signed certificate to the SRX device. In the case of this exercise this was done out of band (files were copied to USB and moved), but in real world deployments would happen in band via email or automated methods. The screenshots below outline the CLI command to generate the CSR.



5. Load CA Certificate
Once the CSR step is complete and the CA has generated the certificates they will need to be loaded on each SRX device. The first one is the CA certificate. Installing the CA certificate allows the device to validate the chain of trust. The screenshots below outline the commands to import the certificate. The certificates were copied from the CA to the SRX with a USB stick.



6. Load Local (signed) Certificate
The second certificate is the CA signed certificate for the local device. This allows the local device to contain a certificate which is trusted/signed by the CA. As in the previous step this certificate was copied from the CA with a USB stick and loaded on to the SRX devices. The commands below import this certificate.




7. Show Local Certificates
The command below displays the local signed certificate information on the SRX devices.



8. Verify CA & Local Certificates
The commands below allow the certificates to be verified against the CA to ensure proper chain of trust. This concludes the steps related to PKI configuration, the remaining steps are IPSec VPN configuration.




Configure IPSec VPN
1. Create Phase 1 Proposal
In previous posts the 'standard' proposal has been used. In this post a custom proposal is used to outline that the authentication method is now rsa-signatures (instead of pre-shared key). The following screenshot outlines the commands to create the phase 1 proposal.



2. Create Phase 1 Policy
In this step the phase 1 policy is created. Local and peer certificates are configured (instead of pre-shared key values).



3. Create Gateways
In the following screenshot IKE gateways are configured. IP addresses are not mandatory as certificates are being used, in the example below host-name is used instead of IP address. In this case DNS on all devices must be configured properly so that the name can be resolved to an IP address.




4. Create Phase 2 Policy, VPN and Security Policies
See details in post SRX IPSec VPN - Multipoint for detailed steps. These steps will be the same regardless of pre-shared key vs. certificate based authentication.


Verify IPSec Operation
1. Show Phase 1 Security Associations
The screenshots below outline that Phase 1&2 security associations have formed properly.




Conclusion
Certificate based IPSec VPNs are more complex and require more infrastructure to operate. Large VPN deployments or deployment with specific requirements may want to use certificate based VPNs for some large scale efficiency gains, for the average small scale deployment pre-shared key is the simplest and might be the best way to go.


No comments:

Post a Comment