[openssl-users] problems with s_client recognizing revoked intermediate/subordinate ca

[Jakob Bohm]

On 10/03/2016 23:41, Viktor Dukhovni wrote:
> On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
>
>>> This is changing in OpenSSL 1.1.0, and may yet change in a future
>>> OpenSSL 1.0.2 update.  Only the trust-anchor (top-most certificate
>> >from the trust-store) is not checked for expiration or revocation
>>> in OpenSSL 1.1.0.
>>>
>>> Intermediate certificates are checked, whether they are from the
>>> trust-store, or acquired from the peer.  To get previous behaviour,
>>> one needs to set the X509_V_FLAG_PARTIAL_CHAIN flag so that the
>>> first certificate found in the trust store becomes the trust-anchor,
>>> and chain construction stops there.
>>>
>>> Another way (in OpenSSL 1.1.0) to get an intermediate certificate
>>> to terminate the chain is to decorate it with explicit auxiliary
>>> trust EKUs via the "-trustout" and "-addtrust" options of "openssl
>>> x509", and then add the decorated certificate to the trust store.
>> This will cause a lot of grief when both OpenSSL versions
>> are used on the same system, (since 1.1.0 is not a drop in
>> replacement for OpenSSL 1.0.x), with the same default trust
>> store directory.
Your reply below is a perfect illustration of the expected confusion.

Try repeating it, this time stating /for each point/ if you are
describing 1.0.2 or 1.1.0 behavior, then how those would differ
in the various situations.  It gets really complicated to explain,
especially when not knowing if the application accessing the store
was linked to 1.0.2 or 1.1.0 .
> I am not sure why there would be a lot of grief, by default the
> partial chain flag is not set, and intermediate certificates are
> not decorated with trust settings, as a result of which the only
> user-visible change is that intermediate certificates that come
> from the trust store will be checked in the same way as they would
> had they arrived from the peer.  This fixes inconsistency of
> behaviour.
>
> The behaviour is *only* different if:
>
>    * The trust store actually includes some intermediate certificates.
>      Usually it contains just the root CAs.
>
> AND either:
>
>    * The application requests partial chains or the intermediate
>      certificates have auxiliary trust EKUs.
>
>      OR
>
>    * Some of the trust-store intermediate CAs are expired or
>      invalid.  (Don't do that).
Note that this discussion started with a situation where an
intermediate CA was *revoked* after being placed in the store.
Outside of testing, a trusting party cannot know that in
advance.
>> It would have been much better to use a separate directory
>> for untrusted chain-building intermediary certificates, just
>> like some other libraries do.
> Intermediate certificates in the trust store are effectively
> untrusted, unless decorated with auxiliary trust settings.  Only
> the "partial chain" flag makes them trusted, applications should
> not generally set that flag.
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded