Google BoringSSL fixed two certificate Name Constraints failures in March, but an accepted URI-name finding is still under coordination. CERT/CC’s October 14 vulnerability note separates five findings by validation path and status. Teams using constrained subordinate certificate authorities need to find out which path their product calls before treating a library update as protection.
A constrained subordinate CA has a signed credential to issue certificates, but only for permitted names. If a validator mishandles a subject alternative name (SAN), a certificate signed by that CA can pass a name check outside the intended scope. The relying application can then authorize access using that out-of-scope name. The certificate may have a trusted signature even as the validator misapplies its name restriction.
Five findings across two validators
RFC 5280 says an excluded name subtree takes precedence over a permitted one. It also applies URI constraints to the host part of the URI. CERT/CC describes four findings in legacy crypto/x509 and one in the newer pki validator:
VU#410595.8: A wildcard DNS name could avoid an exclusion for a particular host on the legacy path. The upstream fix commit describes the exclusion of a specific host matching a wildcard name.VU#410595.9: A colon before@in a URI can make the legacy matcher use the wrong host. CERT/CC lists this finding as accepted and under coordination.VU#410595.10: A first-@domain-extraction question inrfc822Namematching is disputed. The note identifies interpretation of multi-@inputs by consuming mail applications as the point of dispute.VU#410595.11: Trailing-dot handling inrfc822Namedomains concerns the newerpkipath. BoringSSL declined the finding on February 28 as below its security threshold.VU#410595.12: Trailing-dot DNS names were not always normalized on the legacy path.
Oleh Konko discovered and reported the issues. A product needs both an affected name form and the corresponding validation path for these findings to matter. CERT/CC puts the scoping warning plainly: “Using BoringSSL in a product does not mean that product invokes an affected path or name form.” Confirm the validation path before assigning affected status to Chrome, Android or another consumer.
Two fixes landed in March
CERT/CC assigns the March 4 upstream commit 5774eca to .8 and .12. Its status for .9 remains accepted and under coordination; .10 is disputed and .11 was declined. The BoringSSL commit record names the wildcard exclusion change in crypto/x509. Products ship their own BoringSSL copies and deliver updates on their own schedules; verify that the installed product build carries the March fixes.
CERT/CC lists Google and Entrust Datacard with unknown vendor status and says it has received no vendor statement from either. For BoringSSL vendor status, it directs readers to the Google Issue Tracker. Ask the product owner which validator and build handle certificates on the authorization path.
Trace the certificate decision
Start with the service that uses certificate names for authorization. Identify the product build, its bundled BoringSSL revision, whether it enforces Name Constraints through legacy crypto/x509 or newer pki, and which SAN forms it accepts. For the legacy path, obtain the product update carrying the .8 and .12 fixes; track .9 separately while it remains under coordination. Keep issued SANs well formed and restrict the subordinate CA’s issuance authority to the names the service needs.
Then use your product’s supported certificate-validation test path with a trusted constrained test CA: a name inside the allowed scope should pass, while a name excluded by that CA should be rejected at the same authorization decision. Include the relevant wildcard, URI or trailing-dot name form only where that application accepts it. Save the service’s certificate-validation log entry or supported test output for the attempted SAN, together with the presented certificate chain and installed build. The result should show rejection of an excluded name at the same authorization decision. CERT/CC warns that a second validator helps only when it receives the same inputs and fails closed.