[musthaf-bughunter]

Description

CertTree chains certificates on issuer/subject matching and signature validity only (cert.py#L1806), and CertTree.verify checks the validity period and the hostname but never basicConstraints (cert.py#L1845-L1884). Any CA:FALSE certificate issued by a trusted CA can sign a certificate for another name, and the result verifies. With TLSClientAutomaton(verify_server=True) / cafile, a MitM holding a certificate from the trusted CA for its own name passes the chain and hostname checks; CMS_Engine.verify (Kerberos PKINIT) is affected the same way.

Repro with the test PKI (srv_cert.pem is CA:FALSE):

ca = Cert("ca_cert.pem")
srv = Cert("srv_cert.pem")
forged = Cert("srv_cert.pem")
forged.x509Cert.tbsCertificate.issuer = srv.x509Cert.tbsCertificate.subject
forged.x509Cert.tbsCertificate.subject[-1].rdn[0].value = ASN1_PRINTABLE_STRING(b"victim.example")
forged.setSubjectPublicKeyFromPrivateKey(PrivKeyECDSA())
forged = Cert(PrivKey("srv_key.pem").resignCert(forged))
CertTree([forged, srv], ca).verify(forged, hostname="victim.example", now=(2025, 1, 1, 0, 0, 0, 2, 1, 0))
# no exception

verify now rejects a chain that goes through a certificate without cA, and enforces pathLenConstraint (RFC 5280 sect 6.1.4). The trust anchor is not checked, so a non-CA certificate can still be pinned. Tests added to cert.uts.