IPsec Site-to-Site VPN Example with Certificate Authentication

Using certificate-based authentication for identification of VPN tunnel peers is much stronger than using a simple Pre-Shared Key.

Certificate authentication requires a PKI structure. Depending on the setup, each side may utilize its own CA, or they may share a CA. This example will utilize a different CA on each node, to more closely resemble connecting to third parties. CA and certificate entries can be created and imported in the GUI by the Certificate Manager.

Required Information

Endpoint A:

Item

Value

Hostname

office.vpn.example.com

WAN IP Address

198.51.100.16

Endpoint B:

Item

Value

Hostname

home.vpn.example.com

WAN IP Address

198.51.100.17

Create CA

First, create a Certificate Authority (CA) on each side:

On Endpoint A:

  • Navigate to System > Cert Manager, CAs tab

  • Click fa-plus Add

  • Set Descriptive Name to Office VPN CA

  • Set Method to Create an internal Certificate Authority

  • Check Randomize Serial

  • Set Common Name to office-vpn-ca

  • Leave the rest of the fields at their default values, or adjust to suit local preferences

  • Click Save

  • Click fa-certificate to export this CA as a file in the browser

On Endpoint B:

  • Navigate to System > Cert Manager, CAs tab

  • Click fa-plus Add

  • Set Descriptive Name to Home VPN CA

  • Set Method to Create an internal Certificate Authority

  • Check Randomize Serial

  • Set Common Name to home-vpn-ca

  • Leave the rest of the fields at their default values, or adjust to suit local preferences

  • Click Save

  • Click fa-certificate to export this CA as a file in the browser

Import Peer CAs

Next, import the new CA entries into the peer. For example, import the Home CA to the Office side, and vice versa.

Note

This step only requires the certificate data, not the key. The key belonging to the CA should not be copied off the firewall where it was created.

On Endpoint A:

  • Navigate to System > Cert Manager, CAs tab

  • Click fa-plus Add

  • Set Descriptive Name to Home VPN CA

  • Set Method to Import an existing Certificate Authority

  • Paste the contents of the exported Home VPN CA.crt file into Certificate Data

  • Click Save

On Endpoint B:

  • Navigate to System > Cert Manager, CAs tab

  • Click fa-plus Add

  • Set Descriptive Name to Office VPN CA

  • Set Method to Import an existing Certificate Authority

  • Paste the contents of the exported Office VPN CA.crt file into Certificate Data

  • Click Save

Create Endpoint Certificates

On Endpoint A:

  • Navigate to System > Cert Manager, Certificates tab

  • Click fa-plus Add

  • Set Method to Create an internal Certificate

  • Set Descriptive Name to Office VPN Certificate

  • Set Certificate Authority to Office VPN CA

  • Set Common Name to office-vpn-cert

  • Set Certificate Type to User Certificate

  • Set Alternative Names, Type to FQDN or Hostname, Value to office.vpn.example.com

  • Click fa-plus Add

  • Set the new row Alternative Names, Type to IP Address, Value to 198.51.100.16

    Note

    If the IP address is dynamic, skip this step or use the LAN IP address.

  • Leave the rest of the fields at their default values, or adjust to suit local preferences

  • Click Save

On Endpoint B:

  • Navigate to System > Cert Manager, Certificates tab

  • Click fa-plus Add

  • Set Method to Create an internal Certificate

  • Set Descriptive Name to Home VPN Certificate

  • Set Certificate Authority to Home VPN CA

  • Set Common Name to home-vpn-cert

  • Set Certificate Type to User Certificate

  • Set Alternative Names, Type to FQDN or Hostname, Value to home.vpn.example.com

  • Click fa-plus Add

  • Set the new row Alternative Names, Type to IP Address, Value to 198.51.100.17

    Note

    If the IP address is dynamic, skip this step or use the LAN IP address.

  • Leave the rest of the fields at their default values, or adjust to suit local preferences

  • Click Save

Setup IPsec VPN

On both firewalls, configure the IPsec tunnel as described in IPsec Site-to-Site VPN Example with Pre-Shared Keys, with the following exceptions:

Endpoint A:

  • Set Authentication method to Mutual Certificate

  • Set My Identifier appropriately to match the certificate for this endpoint

  • Set Peer Identifier appropriately to match the certificate of the peer

  • Set My Certificate to Office VPN Certificate

  • Set Peer Certificate Authority to Home VPN CA

Endpoint B:

  • Set Authentication method to Mutual Certificate

  • Set My Identifier appropriately to match the certificate for this endpoint

  • Set Peer Identifier appropriately to match the certificate of the peer

  • Set My Certificate to Home VPN Certificate

  • Set Peer Certificate Authority to Office VPN CA

Matching Certificate and Identifiers

In order for the IPsec daemon, strongSwan, to properly match up a certificate and its keys to a peer, the local and peer identifier must match data in the certificate exactly.

Warning

Do not place quotes (single or double) around the identifier values.

There are several ways to accomplish this matching, depending on the environment.

The key factors are:

  • The IPsec daemon must be able to confirm that an endpoint matches the expected identifier, which matches a peer to a specific tunnel.

  • The IPsec daemon must be able to match that identifier to a certificate and validate its trust, which confirms the identity and authenticates the tunnel peer.

The following identifier types are the best practices to use with certificate authentication:

Distinguished Name

This choice can work with fully qualified domain names or short hostnames. If the certificates were created as specified in Create Endpoint Certificates, use the full hostname such as office.vpn.example.com or home.vpn.example.com. This is the easiest choice and most likely to succeed, assuming the SAN value is present in the certificate.

Modern certificates typically include the certificate CN as a SAN entry, so the CN may also be used if it resembles a hostname (e.g. office-vpn-cert). Check the certificate properties to ensure it is present as an FQDN SAN entry. This will not work if the CN contains spaces or other characters not compatible with hostnames.

ASN.1 Distinguished Name

The full ASN.1 Distinguished Name of the certificate. This is similar to the certificate subject but has stricter rules about its order.

This can be formatted in several ways so long as it matches the data in the certificate exactly, for example:

  • /CN=host.example.com/C=US/ST=Texas/L=Austin/O=Example Co

  • CN=host.example.com, C=US, ST=Texas, L=Austin, O=Example Co

  • CN = host.example.com, C = US, ST = Texas, L = Austin, O = Example Co

Note

The type, number, and order of fields will vary depending on how the certificate was made.

To find this string, inspect the certificate in one of the following ways:

  • From the Certificate Manager, Certificates tab, find the entry and click the fa-info-circle icon to expand the certificate details. In the details, copy the contents of the DN: field exactly.

    DN: /CN=host.example.com/C=US/ST=Texas/L=Austin/O=Example Co
    
  • Use OpenSSL on a copy of the certificate contents and look for the Subject contents:

    $ openssl x509 -text -noout -in mycert.crt | grep Subject:
            Subject: CN = host.example.com, C = US, ST = Texas, L = Austin, O = Example Co
    
  • If the certificate is configured in IPsec already, look at how strongSwan reports the certificate subject:

    $ swanctl --list-certs | grep subject
      subject:  "CN=host.example.com, C=US, ST=Texas, L=Austin, O=Example Co"
    

Warning

When copying these values, remember that they must be entered exactly as shown but without any single or double quotes around the string. Only include the DN contents and not any headers or labels such as DN: or Subject:.

My IP Address / Peer IP Address

These choices are viable if all of the following items are true:

  • Both endpoints have static IP addresses

  • These static IP addresses are used as the Remote Gateway address on each side of the IPsec tunnel

  • The static IP address of an endpoint is present in its certificate as a SAN

IP Address

Similar to the My IP Address / Peer IP Address case above, but instead of using endpoint static IP addresses, uses a pre-determined local addresses instead. This could be the LAN IP address or another agreed upon address which does not change. This value does not need to match the Remote Gateway address in this case.

  • The value must be present as an IP address type SAN in the certificate

In most cases, this is not ideal, and the hostname is easier to use instead.

Troubleshooting

If the IPsec daemon cannot match an identifier to a known certificate, the following error is logged on one or both of the peers:

charon[5319]: 08[IKE] <con100000|1> no trusted RSA public key found for '<identifier>'

In that case:

  • Check over all of the identifier data again to ensure that the values exactly match an appropriate certificate field (DN, SAN, etc.)

  • If using an ASN.1 DN, ensure the order of DN/subject components exactly matches the order reported by the DN field in the Certificate Manager, strongSwan, or openssl

  • Ensure there are no single or double quotes around the identifier value in the GUI

  • Ensure the correct Peer Certificate Authority is imported and selected

When attempting a connection, locate the correct con identifier in strongswan by comparing the tunnel settings against the output of the following command in an SSH or console shell:

# swanctl --list-conns

Then attempt to initiate the tunnel with:

# swanctl --initiate --ike conXXXXXXX

When initiating a tunnel in this way, swanctl will output only the relevant logs to the terminal. This is much easier than attempting to follow the log file contents in other ways.

Attempt to initiate the tunnel in both directions and compare output.