[Swan-dev] %fromcert

[Paul Wouters]

On Thu, 7 Feb 2019, D. Hugh Redelmeier wrote:

> Documentation (in programs/configs/d.ipsec.conf/leftid.xml):
>
> 	The magic value
> 	<emphasis remap='B'>%fromcert</emphasis>
> 	causes the ID to be set to a DN taken from a certificate that is loaded.
> 	Prior to 2.5.16, this was the default if a certificate was specified.
>
> This doesn't say which certificate (there might be several) or when it
> is taken or if it might be taken multiple times.

There can only be one leftcert= pointing to one certificate.

For receiving CERT payloads over IKE, there can be multiple but these
are dropped. There is only supposed to be one CERT (chain) containing
one EE cert.

> Logically, one might expect that the name would be reset if the
> certificate were unloaded, but it doesn't say that.  Can certificates
> be unloaded?  Expiry?  CRL?  Some kind of whack command?

We will still use expired certificates. The other end is responsible for
verification of our certificate. It might be that we refuse to load
expired certificates, so conns with those should fail to load.

> Are you saying that it only applies to a cert that we got through {left,right}cert= ?
> The documentation doesn't say that.
> I have no idea if the code says that.

No. It applies to loaded certs and certs received over IKE. the latter
is in instances of the conn.

> - if the certificate changes.  I don't see why this is logically
>  linked with loading a conn and yet that is the only way of resetting
>  the %fromcert.

The NSS database is opened readonly and pluto cannot write to it. While
it would be nice to be able to update the certificate outside of pluto
(eg using letsencrypt importing a fresh one), I don't think pluto will
be aware of this new certificate until it reloads the NSS database,
which currently happens during startup (it would be hard to do, if any
IKE sessions are up since it would have state and references into this 'old'
runtime db)


> - there are multiple certificates presented to match_certs_id.  Any of
>  or all of their derNames might be suitable.

That might be an actifact when we need to extract a full path over
intermediary certificates? I'm not sure. Perhaps it should only ever
get the EE cert?

Paul