[openssl-users] problems with s_client recognizing revoked intermediate/subordinate ca
noloader at gmail.com
Fri Mar 11 04:14:12 UTC 2016
>> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
>> >but also as a capricious source of intermediate certificates, whose
>> >behaviour varies depending on whether the peer supplied same said
>> >certificates on the wire or not. I expect to improve the capricious
> They are not trust-anchors, so absent an issuer higher up, they
> are not sufficient to establish a "chain of trust", unless the
> application enables "partial chain" support.
> However, in 1.0.x (more bug than feature) basic constraints, key
> usage constraints and EKU constraints, which are applied to
> intermediate certificates provided by the peer, are not applied
> when the intermediate certificates happen to originate from the
> trust store.
This seems like its a tricky area... The IETF and CA/B have different
issuing and usage policies, and there's no way to determine under what
policy a certificate was issued. You can kind of find CA/B sometimes
if they have one of those Extended Validation certificates based on
the cornucopia of OIDs. But IETF is Persian Bazaar because they lack a
way to denote policy.
If its a certificate issued under the IETF, then key usage expands
with the EKU of an intermediate. Under the CA/B, the EKU of an
intermediate contracts or constrains key usage.
More information about the openssl-users