Indirect CRL CLI and support
Wade Cline
wadecline at hotmail.com
Fri May 1 05:23:47 UTC 2020
Hello,
I have the following PKI:
root_ca
/ \
localhost signing_ca -
/ | \
admin friend referrer -
| \
referred referred_bad_indirect (R)
'admin', 'friend', 'referred', and 'referred_bad_indirect' are all client
certificates while the others are CAs ('referrer' has a 'pathlen' of '0').
My goal is to revoke the 'referred_bad_indirect' certificate via the
'signing_ca' using an indirect CRL.
>From what I've read on an old forum post about Indirect CRLs [1] it seems
possible to add the "CRL Distribution Points" extension [2] to the
'referred_bad_indirect' certificate and to add the "Issuing Distribution
Point" extension [3] to the issued CRL; however, it seems that the CRL
also needs to have at least one "Certificate Issuer" extension [4] for each
certificate that is not revoked by the CRL issuer. This does not appear to
be possible with the current `crl` tool provided by OpenSSL as the CRL is
generated from the plaintext database which does not appear to have support
for certificates issued by other CAs.
For completeness, I tried out [5] a set-up similar to the one mentioned in the
old Indirect CRL forum post mentioned earlier [1]:
root_ca -----------------------
/ \ \
localhost signing_ca_indirectcrl crl_ca
/ \
friend_indirect friend_bad_indirect (R)
I was able to get the "CRL Distribution Points" extension added to
'friend_indirect' and 'friend_bad_indirect' and also the "Issuing Distribution
Point" to the CRL generated by 'crl_ca', but was not able to verify that
'friend_bad_indirect' was actually revoked, which I expect is due to the fact
that the CRL does not have a "Certificate Issuer" extension and the CRL
issuer does not match the issuer of the 'friend_bad_indirect' certificate,
which is how I interpet [1]:
As written, both user credentials successfully validate because the CRL
generated does not include the issuer extension on each of its entries. If
you choose common names such that the CA credential, CRL issuer credential, and
CRL issuer named in the user certificates are all the same, the verify command
will successfully recognize that one of the user credentials has been revoked.
So at this point it seems to be that the problem is a lack of the "Certificate
Issuer" extension on the generated CRL. My questions are thus:
1) Is it possible to generate an indirect CRL with appropriate
"Certificate Issuer" extensions via the OpenSSL CLI tools?
2) If not, is this supported via the library API?
3) Does OpenSSL fully support verifying an indirect CRL if one is
provided?
4) Lastly, referring to the first PKI, what would happen if
'referred_bad_indirect' left out its "CRL Distribution Points"
extension (perhaps a lazy or malevolent 'referrer' CA), but the
'signing_ca' issued an indirect CRL with 'referred_bad_indirect'
revoked? Would the revocation be ignored because
'referred_bad_indirect' lacked a "CRL Distribution Points" extension
or would it the revocation be accepted regardless because it's in
the CRL?
My version of OpenSSL is 'OpenSSL 1.1.1g 21 Apr 2020', provided by the Gentoo
system distribution.
Thanks,
Wade
[1] http://openssl.6102.n7.nabble.com/Re-openssl-org-3097-Incorrect-revocation-status-with-indirect-CRL-td47482.html
[2] https://tools.ietf.org/html/rfc5280#section-4.2.1.13
[3] https://tools.ietf.org/html/rfc5280#section-5.2.5
[4] https://tools.ietf.org/html/rfc5280#section-5.3.3
[5] https://github.com/clinew/inspircdtests/blob/indirect_crl/afr.sh#L437
More information about the openssl-users
mailing list