Bonjour, Le 22/08/2013 14:56, Peter1234 a écrit :
You misunderstand how it’s supposed to work. OpenSSL does not prevent you from signing anything. It can’t; for example, you could use other software and generate the signature.Instead, when the recipient gets a certificate, and verifies the chain, it should reject the chain because the signing CA was not legitimate (pathlen exceeded). Hi Rich, following lines are copied from RFC 5280: The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit (Section 4.2.1.3). In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path. (Note: The last certificate in the certification path is not an intermediate certificate, and is not included in this limit. Usually, the last certificate is an end entity certificate, but it can be a CA certificate.) A pathLenConstraint of zero indicates that no non- self-issued intermediate CA certificates may follow in a valid certification path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, no limit is imposed. I assumed openssl would conform to RFC standards and therfore supposed that it takes care of pathlengths specified in CA certificates.
This applies to "relying parties", i.e. the entity that performs the certificate validation. As Rich wrote, anybody having the private key could sign anything (even without OpenSSL), and it's the relying party duty to verify that the certificate chain matches constraints. In that role, OpenSSL correctly checks those constraints.
Take your CA3 example, sign another certificate below it, and ask OpenSSL to verify the chain.
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
