ITADN

SAN validation fails on intermediate/issuing cert

#585Closedvinzent 创建于 2022-10-05
lifecycle/rotten
V
vinzentcommented
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 条评论