Attempting an SSL connection with a cert containing a CRL distribution point extension like that below:
i.e. with a non-asn1_NOVALUE cRLIssuer.
It requires a little instrumentation to get the stacktrace for the
exception. The top of it is:
The root cause of the problem seems to be in ssl_crl_hash_dir:lookup/3
which effectively has to choose between two similar looking 'Issuer'
entities: 'CertIssuer' is a singleton, but 'CRLIssuer' is potentially
a list, but both are treated as if singletons.
I think this selection is as required by [RFC5280,6.3.3(b)1], roughly:
Perhaps only the 'else' branch has been exercised until now?
However, this does make the assumption that cRLIssuer is a SEQUENCE of
length exactly 1, or asn1_NOVALUE. But, for better or worse, the
current usage of pubkey_crl:dp_crlissuer_to_issuer() already makes
I'm not steeped well enough in RFC5280 to guess what the implied
semantics of a list of len > 1 would be; the openssl implementation
does seem to handle a list of general length and the semantics appear
to be 'if any dp_issuer matches crl_issuer'.
Repro and test
I've looked through the OTP SSL tests for somewhere suitable to drop
in a case for this, but it's all rather new territory for me. I'm sure
the following is the wrong place, but it does seem to provoke the
And the backtrace I get (I need to instrument
ssl_handshake.erl:certify catch to see it) is the same as shown at the
Adding my investigatory means I don't get the indicative traceback,
suggesting my patch may be effective. But it still leaves two other
errors. I think I may be turning an 'intentionally invalid'
crl_section into something valid. I think maybe the testing should go
somewhere else, but I'm not sure where would be good.