Re: [PATCH 6/7] virNetTLSCertSanityCheck: Validate all concatenated certs
On Fri, Jul 18, 2025 at 09:39:22AM +0200, Peter Krempa wrote:
On Thu, Jul 17, 2025 at 17:02:33 +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 17, 2025 at 05:28:09PM +0200, Peter Krempa via Devel wrote:
> > From: Peter Krempa <pkrempa(a)redhat.com>
> >
> > Similarly to how we iterate the list of CAs in the concatenated bundle
> > there's a possibility of the server/client certificates to be
> > concatenated as well.
> >
> > If for some case the first certificate is okay but the further one have
> > e.g. invalid signatures the validation code would not reject them but
> > we'd encounter failures later when gnutls tries to use them.
> >
> > Iterate also the client/server certs rather than just the CAs.
>
> Was there some bug that motivated this change ?
Yes-ish. I've abused the fact that gnutls loads everything from the file
...
>
> I'd like to keep libvirt's behaviour in sync with QEMU's
> behaviour to the greatest extent possible. I've just been
> finalizing changes to QEMU to cope with mutliple certs
> in the server-cert.pem file, but the semantics there are
> the certs are a chain of intermediate certs, all of which
> must be valid.
>
> ie, currently we allow
>
> ca-cert.pem server-cert.pem
> | |
> |------+--------------------------| |---+-------|
>
> Root CA -> Sub CA 1 -> Sub CA 2 -> Server Cert
>
> but the intent is to support
>
> ca-cert.pem server-cert.pem
> | |
> |------+--| |----------------------------+-------|
>
> Root CA -> Sub CA 1 -> Sub CA 2 -> Server Cert
>
>
> Or
>
> ca-cert.pem server-cert.pem
> | |
> |------+-------------| |---------------+-------|
>
> Root CA -> Sub CA 1 -> Sub CA 2 -> Server Cert
... meant to facilitate the above ....
>
> the rational is that these splits reflect how some CA will
> give you your certs to begin with, and we want to allow
> them to be used directly.
>
> My intent was to copy the QEMU change into libvirt once it
> was merged in QEMU, so from that POV I'm not a fan of making
> the some of the changes in this series.
>
> Beyond that I'm also working post-quantum crypto support,
> which will require us to load multiple distinct server-cert-NNN.pem
> files, each with an independant set of certs, which are selected
> at runtime based on negotiated ciphers in the TLS handshake.
... in order to load certs with different (also the fancy new
post-quantum) signature algorithms.
To best of my knowledge that will not work. IIUC when you load
a bundle of certs into a session with gnutls_credentials_set
that is assumed to be a cert chain by GNUTLS.
To load multiple parallel certs, with different algorithms
requires calling gnutls_credentials_set mutliple times,
providing each distinct cert chain.
Kind of annoying since it means every app using gnutls is
guaranteed to need code changes to support PQC with
parallel offerings of algorithms.
Since I didn't notice that the crypto policy in fedora 42
doesn't yet
trust some of those (e.g. mldsa65), some of the certificates I've
concatenated weren't actually passing the checks.
Yep, even in rawhide the PQC stuff isn't fully ready for gnutls.
The only place I'm aware of which has new enough gnutls is CentOS
Stream, and even then you need custom crypto-policies to enable
it fully.
Thus if you're going to be fixing both of these I'll just
push the
cleanup patches.
Yep, go ahead and push the cleanup ones
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|