diff options
author | Magnus Henoch <[email protected]> | 2016-01-22 12:31:36 +0000 |
---|---|---|
committer | Magnus Henoch <[email protected]> | 2016-02-17 10:24:11 +0000 |
commit | 331afa5dfaa129a5ea41af5dd76246bb922ac7df (patch) | |
tree | 489deae2e97d50d9905408a6e4404b00e624cc8b /lib/debugger | |
parent | 56b40d01c47170fea0d798dcc46fbde7ffc853dc (diff) | |
download | otp-331afa5dfaa129a5ea41af5dd76246bb922ac7df.tar.gz otp-331afa5dfaa129a5ea41af5dd76246bb922ac7df.tar.bz2 otp-331afa5dfaa129a5ea41af5dd76246bb922ac7df.zip |
Be suspicious of certificates without CRL DPs
Previously, if certificate revocation checking was turned on, and a
certificate didn't contain a CRL Distribution Points extension, and
there was no relevant CRL in the cache, then ssl_handshake:crl_check
would accept the certificate even if the crl_check option was set to
reject certificates for which the revocation status could not be
determined. With this change, such certificates will only be accepted
if the crl_check option was set to best_effort.
The process for CRL validation is described in section 6.3 of RFC
5280. The text doesn't mention any special treatment to be given to
certificates without distribution points: it just says "For each
distribution point..." (section 6.3.3), which would leave the
revocation status undetermined, unless there were "any available CRLs
not specified in a distribution point but issued by the certificate
issuer". Thus the result of this algorithm should be UNDETERMINED in
this case, not UNREVOKED, and the crl_check option should govern how
the implementation reacts to this result.
Diffstat (limited to 'lib/debugger')
0 files changed, 0 insertions, 0 deletions