[codesniperjoe]

> TLS handshakes now return a CertificateVerificationError if they fail because of, well, certificate verification.

... as long the crypto/x509 CheckSignatureFrom ignores the pathlen contraint (the /ONLY/ way of an CA Owner pin down a delegated SubCA usage/raw-key-abuse!) im not sure that CertifictionVerification does what a high-level api user expects!?

[FiloSottile]

CheckSignatureFrom is a low-level API that can't check anything about the path (including more important constraints such as nested EKUs and Name Constraints) because it can only see the immediate parent.

The high-level certificate verification API is Verify, which does check all of the above, see https://pkg.go.dev/crypto/x509#TooManyIntermediates.

We should probably add a line to the docs, to avoid users getting confused like this, but I haven't seen misused in the wild.

(I also disagree that maxPathLen does anything about raw key abuse, since once you have the key of an intermediate you can issue leaves arbitrarily, without needing to issue another intermediate, but that's besides the point.)

[FiloSottile]

There we go. https://go.dev/cl/460537

[codesniperjoe]

Thank you! That is a quick (helpful) fix!

Beside of checks for the integrity of SelfSigned Certificates, I do not used this function directly.

My assumption about the TLS impact was based on the fact that [Certificate.Verify] uses internally [Certificate.buildChains] who calls [Certificate.CheckSignatureFrom], who has only the direct parents IsCA status, but not the full picture of the full path (and ignores it at the end, when missing on the root-Anchor)!?

And yes, in general, the max pathLen helps only to restict the impact of a specific (delegated) subCA compromise, not for a full root CA key leak. But I expect to see a well prepared narrative about a (revokeable) SubCA as most likely response, to protect the Root-Anchor itself. (What a happy co-incidence that the most Root-Anchors do not declare the planned SubCA strategy via maxPathlen upfront.)