Support verifying links (spanningtree) by CA instead of fingerprint

[kylef]

Description

Currently to verify a linked host with TLS, fingerprints are used. This feature request would allow using a certificate authority to verify instead.

This could look something like:

<link ...
  cacert="my-ca.pem">

If the hosts certificate validates with the ca, then it is deemed valid (i.e, the certificate is not expired, etc). Revocation should ideally be supported.

The design of the feature must allow multiple CA roots to facilitate root rotations. A subject filter may be desirable if using a CA that is not isolated to the InspIRCd setup. For example:

<link ...
  cacert="my-ca.pem"
  casubject="*.example.net">

Why this would be useful

Routine certificate renewals require updating the fingerprints in all hosts which makes certificate rotation more complicate, CAs are the standard in which most PKI operates.

Further, it would be nice to not even have to declare servers via a link block and fully trust PKI. Currently servers must share information about each other out of bound.

[SadieCat]

FWIW you can define multiple <sslprofile> tags so you have one that uses a longer lasting self-signed certificate with fingerprint pinning for server connections and another that uses a CA-verified certificate for user connections. I'll look into this though.

[henk84]

I think this is more of a bug than an enhancement.
In times where certs are free and very widespread through all different kinds of services, my expectation was that without my explicit say-so, any TLS connection will verify the cert presented or warn if it cannot verify the cert.
Breaking this expectation by simply not doing verification at all without informing the user should be considered a bug, nowadays, when "security by design" is a widely accepted design principle.
Please make it a priority to change this behaviour, at the very least by adding a warning whenever a cert is encountered that cannot be verified against a fingerprint or a CA.