aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/Makefile
diff options
context:
space:
mode:
authorMagnus Henoch <[email protected]>2016-01-22 12:31:36 +0000
committerMagnus Henoch <[email protected]>2016-02-17 10:24:11 +0000
commit331afa5dfaa129a5ea41af5dd76246bb922ac7df (patch)
tree489deae2e97d50d9905408a6e4404b00e624cc8b /lib/compiler/src/Makefile
parent56b40d01c47170fea0d798dcc46fbde7ffc853dc (diff)
downloadotp-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/compiler/src/Makefile')
0 files changed, 0 insertions, 0 deletions