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 but it is more difficult to configure and manage.

Certificate authentication requires a PKI structure. Depending on the setup, each side may utilize its own certificate authority (CA) or they may share a common CA. This example utilizes a different CA on each node to more closely resemble connecting to third parties.

See also

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 > Certificates, CAs tab

  • Click fa-plus Add

  • Set the options as follows:

    Descriptive Name:

    Office VPN CA

    Method:

    Create an internal Certificate Authority

    Randomize Serial:

    Checked

    Common Name:

    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 > Certificates, CAs tab

  • Click fa-plus Add

  • Set the options as follows:

    Descriptive Name:

    Home VPN CA

    Method:

    Create an internal Certificate Authority

    Randomize Serial:

    Checked

    Common Name:

    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 > Certificates, CAs tab

  • Click fa-plus Add

  • Set the options as follows:

    Descriptive Name:

    Home VPN CA

    Method:

    Import an existing Certificate Authority

    Certificate Data:

    Paste the contents of the exported Home VPN CA.crt file.

  • Click Save

On Endpoint B:

  • Navigate to System > Certificates, CAs tab

  • Click fa-plus Add

  • Set the options as follows:

    Descriptive Name:

    Office VPN CA

    Method:

    Import an existing Certificate Authority

    Certificate Data:

    Paste the contents of the exported Office VPN CA.crt file.

  • Click Save

Create Endpoint Certificates

On Endpoint A:

  • Navigate to System > Certificates, Certificates tab

  • Click fa-plus Add

  • Set the options as follows:

    Method:

    Create an internal Certificate

    Descriptive Name:

    Office VPN Certificate

    Certificate Authority:

    Office VPN CA

    Common Name:

    office-vpn-cert

    Certificate Type:

    User Certificate

    Alternative Names:
    Type:

    FQDN or Hostname

    Value:

    office.vpn.example.com

  • Click fa-plus Add

  • Set the new row options to:

    Alternative Names:
    Type:

    IP Address

    Value:

    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 > Certificates, Certificates tab

  • Click fa-plus Add

  • Set the options as follows:

    Method:

    Create an internal Certificate

    Descriptive Name:

    Home VPN Certificate

    Certificate Authority:

    Home VPN CA

    Common Name:

    home-vpn-cert

    Certificate Type:

    User Certificate

    Alternative Names:
    Type:

    FQDN or Hostname

    Value:

    home.vpn.example.com

  • Click fa-plus Add

  • Set the new row options to:

    Alternative Names:
    Type:

    IP Address

    Value:

    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:

Authentication method:

Mutual Certificate

My Identifier:

Set appropriately to match the certificate for this endpoint

Peer Identifier:

Set appropriately to match the certificate of the peer

My Certificate:

Office VPN Certificate

Peer Certificate Authority:

Home VPN CA

Endpoint B:

Authentication method:

Mutual Certificate

My Identifier:

Set appropriately to match the certificate for this endpoint

Peer Identifier:

Set appropriately to match the certificate of the peer

My Certificate:

Home VPN Certificate

Peer Certificate Authority:

Office VPN CA

Matching Certificate and Identifiers

In order for the IPsec daemon to properly match 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. 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:

Fully Qualified Domain 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.

Warning

This mode 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

Attempt to initiate the tunnel in both directions manually and compare output (Manually connect IPsec from the shell).