SAN validation fails on intermediate/issuing cert
lifecycle/rotten
For bug 2052467 in merge-request #545 validation of all certs for a SAN was added:
https://github.com/openshift/cluster-authentication-operator/blob/265030f6ebe691184348d7eff7398dd3ff912a3e/pkg/operator/datasync/validation.go#L92-L96
This check fails, if one provides additional intermediate/issuing certs. Leaving the cluster in not-upgradable/degraded state. This is a not uncommon configuration if clients only receive the root-ca (the one signed the intermediate/issuing cert). If the server sends the intermediate/issuing cert additionally, this allows the client to verify the trust chain. Trust chain:
1. "Route"/sender/server Cert (sent by the server)
2. Intermediate/Issuing CA (sent by the server)
3. Root CA (in clients trust-store)
Providing additional certs is covered in [RFC-8446 Section 4.4.2](https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2).
> If the corresponding certificate type extension
> ("server_certificate_type" or "client_certificate_type") was not
> negotiated in EncryptedExtensions, or the X.509 certificate type was
> negotiated, then each CertificateEntry contains a DER-encoded X.509
> certificate. The sender's certificate MUST come in the first
> CertificateEntry in the list. Each following certificate SHOULD
> directly certify the one immediately preceding it. Because
> certificate validation requires that trust anchors be distributed
> independently, a certificate that specifies a trust anchor MAY be
> omitted from the chain, provided that supported peers are known to
> possess any omitted certificates.
IMHO the SAN validation should only cover the FIRST certificate and not EVERY, as this MUST be the senders certificate according to the RFC.
关闭于 2023-03-05 4 条评论