ipsec: strongswan: pubkey auth trusted CAs

[reet-]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

I'm in the process of migrating an IPsec roadwarrior setup currently configured in the legacy tunnel settings to the new Connections interface.

Our current pubkey auth settings in the legacy tunnel settings for the remote looks like this:

# swanctl --list-conns
...
  remote public key authentication:
    id: %any
    cacerts: C=de, O=example, CN=ca

Whereas a new connection config results in:

# swanctl --list-conns
...
remote public key authentication: (nil)

I found no way to only allow roadwarriors under a specific CA to connect.

Describe the solution you like

For pubkey auth it should be possible to only allow one or more trusted CAs.

Describe alternatives you considered

Also specifying a wildcard match (e.g. C=de, O=example, CN=* in the Remote Authentication Id field does not work even though strongswan supports this. Furthermore the Id field does not allow whitespaces but they are common in certificates. Both C=de, O=example and O=my Project are rejected.

[jfbelanger-rruq]

I'm in the process to migrating my config to the new interfaces too, and it is missing the cacert options, and I'm unable to put the = sign in the local id.

For reference, this is my old working swantctl config:
local-0 {
id = CN = opnsense.domain.com
auth = pubkey
certs = cert-2.crt
}
remote-0 {
id = %any
auth = pubkey
cacerts = test-ca.crt
}

There seem to be a note in the Swanctl.xml that point to that setting missing:
XXX add cacert field + logic in ipsec_write_cas

[AdSchellevis]

@jfbelanger-rruq what happens if you omit the spaces? (CN=opnsense.domain.com)

[jfbelanger-rruq]

@jfbelanger-rruq what happens if you omit the spaces? (CN=opnsense.domain.com)

Thanks, I can submit the form now, it's only missing the cacert config drop down, is there someone assigned to this ?
I can take a look to implement it.

[AdSchellevis]

@jfbelanger-rruq I'm not sure you need the CA as the relevant (trusted) ones are being deployed in the trust store of strongswan, I think the note in Swanctl.xml was just a leftover from when I implemented this.

core/src/etc/inc/plugins.inc.d/ipsec.inc

Lines 931 to 952 in 42a7739

	function ipsec_write_cas()
	{
	global $config;
	$capath = "/usr/local/etc/swanctl/x509ca";
	$cafiles = [];
	foreach (isset($config['ca']) ? $config['ca'] : [] as $ca) {
	$cert = base64_decode($ca['crt']);
	$x509cert = openssl_x509_parse(openssl_x509_read($cert));
	if (is_array($x509cert) && isset($x509cert['hash'])) {
	$fname = "{$capath}/{$x509cert['hash']}.0.crt";
	$cafiles[] = $fname;
	file_put_contents($fname, $cert);
	} else {
	log_msg(sprintf('Error: Invalid certificate hash info for %s', $ca['descr']), LOG_ERR);
	}
	}
	foreach (glob("{$capath}/*.0.crt") as $fname) {
	if (!in_array($fname, $cafiles)) {
	unlink($fname);
	}
	}
	}

To some degree I expect we could also just point the trust store to the one used in the rest of the system, there is some duplication of logic here.

[tobiasbrunner]

I'm not sure you need the CA as the relevant (trusted) ones are being deployed in the trust store of strongswan

That's not necessarily the case. You might have the CA certificates of your own certificate or various different peers in there, but want to enforce that peer/client certificates for a particular connection are only issued by a specific CA.

In @jfbelanger-rruq's case, the certificate for CN=opnsense.domain.com might be issued by Let's Encrypt. And if its root CA certificate is installed as trusted certificate (not necessary, but possible, and the intermediate CA certificate has to be installed to send it to the clients), every certificate issued by Let's Encrypt would be accepted by that config because there are no constraints on the remote ID (id = %any) or the issuing CA certificate (because neither cacerts/cacert*, nor ca_id are currently supported).

[AdSchellevis]

@tobiasbrunner for the remote end this makes sense indeed and shouldn't be difficult to add for us. currently the trust store Strongwan uses on our end only contains the user supplied ones, but that's not a guarantee of course.

Looking at your documentation, I lean towards adding ca_id to constraint the ca part, but since the expert joins the discussion, I would like to ask what's your take on that? (don't want to offer all choices in the world if there's best practice, also to avoid people from getting even more overwhelmed than they likely already are)

[tobiasbrunner]

While ca_id is more flexible (it's an identity, so the CA certificate doesn't have to be available locally), it currently only accepts a single value. And it might not be as straightforward for users if they have to enter the identity themselves (e.g. the full subject DN of the CA certificate, or some SAN, optionally with wildcards) rather than select a CA from a list of available certificates. The setting can also have implications regarding certificate requests (see below).

If there is a use case for allowing client certificates to be signed by one of multiple different CAs, then that's currently only possible with the other settings (unless wildcards can be applied), where the number of loaded certificates is not limited (other than by the size of the vici message). The difference between the other two options is that with cacerts, certificates are loaded by swanctl (inline as hex/base64 blobs, or from files via their absolute paths or relative to the swanctl/x509ca directory) and then passed to the daemon as a list of binary blobs. On the other hand, cacert* sections are ignored by swanctl and will just instruct the daemon to load the certificate, either from an absolute path or from a security token. Compared to ca_id, such CA certificate constraints are a bit stronger (but also more rigid) as they require exact matches of complete certificates in the peer's trust chain.

As mentioned, a possible consideration may also be certificate requests. They are basically hashes of CA public keys, so they can only be sent if a CA certificate is loaded (at least currently). With the latter settings that's a given and corresponding certificate requests can be sent (only requests for the configured CA certificates are sent - without constraints, all loaded CA certificates are included). When using the ca_id setting, that might not be the case if no CA certificates, not even for the local trust chain, are loaded. It depends on the peer whether any certificate requests are necessary or it sends its certificate also without (e.g. strongSwan won't unless send_cert = always is configured), and also whether it needs a specific certificate request to select the correct client certificate if it has multiple available.

So it depends on what use cases you want to cover and maybe the GUI you want to provide to the users. ca_id just needs a text field, but the users have to know what to enter. The other settings probably require a list of available certificates to choose from, which is easier for the user but a more complex interface (but maybe such a GUI element already exists?). Providing users the option to configure both for the same connection probably isn't useful, so CA constraints should either be one or more CA certificates, or an identity, but not both. To me, the ca_id setting has more of an "advanced user"-feel to it, having a list of existing CA certificates to choose from seems more straightforward.

Also, regarding the remote identities (including ca_id if you decide to expose that setting in the GUI), support for wildcards and accepting spaces would definitely be helpful to match more complex subject DNs (and wildcards can also be used to match SANs, like *@example.org).

[AdSchellevis]

@tobiasbrunner thank you for your elaborate response, I've learned some things.

Adding spaces and wildcards for matching is an easy fix, I seem to have missed the fact that these are valid, so I'll add them. looking at ca matching, I lean towards just adding a list of CA's on our end (cacerts ) as this indeed feels more user friendly. If someone needs ca_id for good reasons in the future, we can also add that as well, but logically with a constraint on top as you shouldn't use both.

[tobiasbrunner]

Sounds good, thanks!

[AdSchellevis]

@jfbelanger-rruq can you try 6de0f4d? with the help of @tobiasbrunner, I've made some modifications which hopefully fills the gap here.

opnsense-patch 6de0f4d10ae0dc19cc551b92d1e16d537caa231e