Intermediate certs should be trusted by default when root CA is trusted

[semik]

At this moment, Intermediate certificates are not trusted by default when root is trusted.

For example site vps.tomasek.cz has certificate issued by Let's Encrypt. I manually uploaded ISRG Root X1 root and marked it s trusted. Later i uploaded certificate of my site, CZERTAINLY marked it as Validation Status = Invalid. I noted that intermediate is not automatically loaded (see https://github.com/3KeyCompany/CZERTAINLY-Core/issues/783), so I added R11 Intermediate manualy. But I did not set Trusted CA = true, in fact I kept it untouched.

CZERTAINLY was still marking certificate of vps.tomasek.cz as untrusted. Untill I marked R11 as trusted.

I think that CZERTIANLY should behave as browsers, or OpenSSL. Browser has trusted root CA preinstalled and marked as trusted by browser vendor. Intermediate CAs are being provided via TLS handshake during establishing connection to HTTPS site. And without any action from user, the certificate of the site is trusted.

In case of Intermediate CA maybe the trusted CA switch needs to be used in different way:

• not trusted
• inherit from root (default)
• trusted

I'm doubtful about trusted state - in case when root is not trusted, intermediate should be also not trusted. Probably first two values are enough.

[3keyroman]

Building the certificate chain and validation process for certificate is described here: https://docs.czertainly.com/docs/certificate-key/concept-design/core-components/certificate#validation.

CZERTAINLY is trying to build the complete chain from information that is available in the certificate inventory and from the extensions of certificate (like AIA). The validation check is performed only when the complete certificate chain is available.

For certificates, that does not include AIA, user should upload certificates of CA to the inventory to have complete chain.

Every CA certificate is initially untrusted, because we want to keep the control on the trusted chains. User should be responsible to define, what is trusted, and what is not, even when there are multiple subordinate CAs issued by one single root CA. Automatic trust for all issued certificates under the root CA may not be the desired behaviour, especially when you would like to split the trust, using similar techniques like certificate pinning.

From my perspective, what you proposed is effectively the same as the current behaviour, where you can mark the CA certificate, or self-signed certificate, as trusted.