[strongSwan-dev] Feature request: direct loading of certs and cert like fields as string data in addition to file paths

[Tobias Brunner]

Hi Joshua,

> From the first email, `connections { "my_conn": {
> "local": {"cert": {"data": <CERTIFICATE STRING>} } } }` doesn't work. 

No, it won't, because no "data" key is expected in a "cert" section
(don't know where you got that from, there is no mention of such a key
in the swanctl.conf documentation).  Binary certificate blobs are
transmitted in a list for the "certs" key, i.e. something like:

  connections {
    "my_conn": {
        "local": { "certs": [<CERTIFICATE STRING>] }
    }
  }

What you have to remember is that swanctl.conf is interpreted by
swanctl.  And since we can't expect users to configure binary blobs
(which is actually also possible in hex and base64 encoding), they
configure files instead.  So unless otherwise mentioned, whenever files
are expected for an option these are first loaded by swanctl and binary
blobs are then actually transmitted in the vici message.

> But there are ways to link to a
> certificate file in that connection.  For instance, `connections {
> "my_conn": { "local": {"cert": {"file": <CERTIFICATE PATH>} } } }` is
> documented explicitly to work.

Yes, the cert section can either take a file path (sent as it to the
daemon), or handle/slot/module to access certificates on tokens/TPMs.

> Something we have found out since then is that certificates seem to
> associate with connections by the ID field in `connections { "my_conn" :
> { "local" : { "id" : <name/altName/id in cert> } , "remote" : { "id" :
> <name/altName/id in cert>} } }` and to have certs loaded separately as `
> { "type" : "x509", "flag" : "None", "data" : <cert blob> }` where the
> cert ID is specified in the cert and not in the Vici config.

Yes, that's possible too.  And it is not specific to vici.  All loaded
certificates (e.g. those automatically loaded from tokens by the pkcs11
plugin) and public keys (e.g. loaded via dnskey plugin) are associated
with matching identities.

Regards,
Tobias