When using envoy_grpc for xds, allow_expired_certificate can be set on the cluster's tls validation context (here). google_grpc has no configurability for this.
When there are multiple certs with same Subject DN but one is expired, the expired can be picked. This was exposed by envoy 1.38 upgrade where boringssl was upgraded, boringssl changed the sorting and now the expired was getting selected (google/boringssl@20cb834).
google_grpc is being used over envoy_grpc as it supports filed based credentials via FileBasedMetadataConfig.
--
There is no option in google grpc to configure X509_V_FLAG_NO_CHECK_TIME from what I can see, TlsCredentialsOptions. Perhaps a check_validity_period which configures X509_V_FLAG_NO_CHECK_TIME can be added in grpc?
Happy to contribute given a suggested path forward here.
When using envoy_grpc for xds, allow_expired_certificate can be set on the cluster's tls validation context (here). google_grpc has no configurability for this.
When there are multiple certs with same Subject DN but one is expired, the expired can be picked. This was exposed by envoy 1.38 upgrade where boringssl was upgraded, boringssl changed the sorting and now the expired was getting selected (google/boringssl@20cb834).
google_grpc is being used over envoy_grpc as it supports filed based credentials via FileBasedMetadataConfig.
--
There is no option in google grpc to configure X509_V_FLAG_NO_CHECK_TIME from what I can see, TlsCredentialsOptions. Perhaps a check_validity_period which configures X509_V_FLAG_NO_CHECK_TIME can be added in grpc?
Happy to contribute given a suggested path forward here.