Re: [PATCH 6/7] virNetTLSCertSanityCheck: Validate all concatenated certs

On Fri, Jul 18, 2025 at 09:24:05 +0100, Daniel P. Berrangé wrote: > 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&gt; > > > > > > > > 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. Well with my test setup where I've: - created 2 CAs (one with RSA one with MLDSA sig) and concatenated them - created 4 server certs RSA+MLDSA sig both signed by each of the above CAs - created 4 client certs same as server certs. I've then concatenated all 4 server certs into one file and sequentially tested connecting with each of the 4 client certs.