Indirect CRL CLI and support
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
Re: OpenSSL version 3.0.0-alpha1 published
On Sun, 26 Apr 2020 11:35:14 +0200, Yann Ylavic wrote: > > On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx wrote: > > > > On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote: > > > > > > - DH_bits(dh) (used for logging only in httpd) > > > Replaced by BN_num_bits(DH_get0_p(dh)). > > > Not sure this one should be deprecated, it seems to be used in several > > > places in openssl codebase still, no replacement? > > > > I think the replacement is using the EVP_PKEY API and then use > > EVP_PKEY_bits() > > Sure, but if all you have is a DH object (say obtained by > DH_get_2048_256() or PEM_read_bio_DHparams()), the EVP_PKEY API does > not help. > It seems a bit odd to me that DH_bits() or DH_security_bits() are > deprecated, but not DH_get0_*() or DH_get_length() for instance. The DH_get0_* functions are useful in contructing other low-level DH objects using the same numbers as the one you currently have. I don't quite see that DH_bits() would be useful in that manner. Along that line of thinking, I agree that it's odd that DH_get_length() wasn't deprecated. I can't remember if it was discussed in particular... it might simply be an omission. All that being said, DH_bits() was undeprecated yesterday. See https://github.com/openssl/openssl/pull/11669 Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, 01 May 2020 01:22:34 +0200,
Sam Roberts wrote:
>
> On Fri, Apr 24, 2020 at 9:07 AM Nicola Tuveri wrote:
> > At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was
> > already an example of how to do this programmatically, and a link to the
> > manpage for the config file syntax.
>
> That's not working for me:
>
> Failed to load Legacy provider: error:2567:DSO support
> routines::could not load the shared library
> /home/sam/w/core/tls/./node[26693]: ../../src/node_crypto.cc:6804:void
> node::crypto::InitCryptoOnce(): Assertion `"Unreachable code reached"'
> failed.
> 1: 0x557630598d84 node::Abort() [/home/sam/w/core/tls/./node]
>
> From:
> /* Load Multiple providers into the default (NULL) library context */
> auto legacy = OSSL_PROVIDER_load(0, "legacy");
> if (legacy == nullptr) {
> unsigned long err = ERR_get_error();
> fprintf(stderr, "Failed to load Legacy provider: %s\n",
> ERR_error_string(err, nullptr));
> UNREACHABLE();
> }
> auto deflt = OSSL_PROVIDER_load(0, "default");
> if (deflt == nullptr) {
> unsigned long err = ERR_get_error();
> fprintf(stderr, "Failed to load Default provider: %s\n",
> ERR_error_string(err, nullptr));
> OSSL_PROVIDER_unload(legacy);
> UNREACHABLE();
> }
>
>
> I notice that the legacy.so isn't in the same folder as the other .so
> files, so I tried:
>
> LD_LIBRARY_PATH=/usr/local/stow/openssl-3.0.0-alpha1/lib:/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules
>
> But that didn't work.
>
> It looks like adding this did work:
>
> OSSL_PROVIDER_set_default_search_path(0,
>"/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules");
>
> What are the default values? I built with prefix set to /usr/local,
> but then installed to the DESTDIR directory above, is that what caused
> me trouble?
You can find out the default value with 'openssl info -modulesdir'
Yes, running from the DESTDIR "installation" gets you into trouble.
DESTDIR is intended to be a staging directory, i.e. a place to put
files that you want to put in an archive or package for more proper
(distribute) installation in the right place. It can be used for
testing, of course, but you then need to know a little more what
you're doing.
I suggest having a look at doc/man7/openssl-env.pod, it contains a
complete enough catalogue of diverse environment variables that you
can use to affect OpenSSL's internal behaviour. OPENSSL_MODULES is of
particular interest in this case.
Suggested command to read a .pod file comfortably:
perldoc -o man doc/man7/openssl-env.pod
I suspect, btw, that people might wonder why we install provider modules
separately from engines. The simple reason is that they are very
different beasts, but the major one is that provider modules are
intended to be fairly OpenSSL version agnostic, by design. Engines
are unfortunately not version agnostic at all, acutely so since
OpenSSL 1.1.0. So while provider modules do not need to be updated
for every OpenSSL version, engines do.
Cheers,
Richard
>
> Cheers,
> Sam
>
>
>
> > I just added also a minimal config file example to load both the default
> > and the legacy provider in the default library context.
> >
> >
> > Cheers,
> >
> > Nicola
> >
> > On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote:
> >>
> >> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote:
> >> > This one is interesting:
> >> >
> >> > ERR_OSSL_EVP_FETCH_FAILED
> >> >
> >> >
> >> > This means that the algorithm you are trying to use isn't available in
> >> > the loaded providers. Since you should be getting the default provider
> >> > loaded automatically it could be because some legacy algorithms were
> >> > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF
> >> > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're
> >> > using something from that list then that would explain it.
> >>
> >> Can we add the legacy provider, via configuration, or via code?
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, Apr 24, 2020 at 9:07 AM Nicola Tuveri wrote:
> At https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers there was already
> an example of how to do this programmatically, and a link to the manpage for
> the config file syntax.
That's not working for me:
Failed to load Legacy provider: error:2567:DSO support
routines::could not load the shared library
/home/sam/w/core/tls/./node[26693]: ../../src/node_crypto.cc:6804:void
node::crypto::InitCryptoOnce(): Assertion `"Unreachable code reached"'
failed.
1: 0x557630598d84 node::Abort() [/home/sam/w/core/tls/./node]
From:
/* Load Multiple providers into the default (NULL) library context */
auto legacy = OSSL_PROVIDER_load(0, "legacy");
if (legacy == nullptr) {
unsigned long err = ERR_get_error();
fprintf(stderr, "Failed to load Legacy provider: %s\n",
ERR_error_string(err, nullptr));
UNREACHABLE();
}
auto deflt = OSSL_PROVIDER_load(0, "default");
if (deflt == nullptr) {
unsigned long err = ERR_get_error();
fprintf(stderr, "Failed to load Default provider: %s\n",
ERR_error_string(err, nullptr));
OSSL_PROVIDER_unload(legacy);
UNREACHABLE();
}
I notice that the legacy.so isn't in the same folder as the other .so
files, so I tried:
LD_LIBRARY_PATH=/usr/local/stow/openssl-3.0.0-alpha1/lib:/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules
But that didn't work.
It looks like adding this did work:
OSSL_PROVIDER_set_default_search_path(0,
"/usr/local/stow/openssl-3.0.0-alpha1/lib/ossl-modules");
What are the default values? I built with prefix set to /usr/local,
but then installed to the DESTDIR directory above, is that what caused
me trouble?
Cheers,
Sam
> I just added also a minimal config file example to load both the default and
> the legacy provider in the default library context.
>
>
> Cheers,
>
> Nicola
>
> On Fri, 24 Apr 2020 at 17:56, Sam Roberts wrote:
>>
>> On Fri, Apr 24, 2020 at 1:05 AM Matt Caswell wrote:
>> > This one is interesting:
>> >
>> > ERR_OSSL_EVP_FETCH_FAILED
>> >
>> >
>> > This means that the algorithm you are trying to use isn't available in
>> > the loaded providers. Since you should be getting the default provider
>> > loaded automatically it could be because some legacy algorithms were
>> > moved to the legacy provider (MD2, MD4, MDC2, RMD160, CAST5, BF
>> > (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES)). If you're
>> > using something from that list then that would explain it.
>>
>> Can we add the legacy provider, via configuration, or via code?
Re: OpenSSL version 3.0.0-alpha1 build failed
For what it's worth, I also get similar perl crashes from the Configure script. All of my build servers (which I do not control) have perl 5.10.1 installed on Oracle Linux 6.5. I tested with 5.12.5 and that also crashed in the same way. 5.14.4 is the oldest version (stable branch) I could find that worked. Tom.III On Thu, Apr 30, 2020 at 2:44 PM Matt Caswell wrote: > This appears to be a bug in perl. You have a very old version of perl > (the oldest we support is 5.10.0). It's probably worth trying to upgrade > it. > > Matt > > > On 30/04/2020 22:12, Ken Goldman wrote: > > My build failed with the below. > > > > x86_64 Linux kernel 2.6.32 > > RHEL 6.7 > > Perl 5.10.1 > > > > Everything through 1.1.1e was successful. > > > > ~~ > > > > > > ./config > > Operating system: x86_64-whatever-linux2 > > Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 > > Using os-specific seed configuration > > *** glibc detected *** /usr/bin/perl: double free or corruption (out): > > 0x02a401e0 *** > > === Backtrace: = > > /lib64/libc.so.6[0x3c2fa75dee] > > /lib64/libc.so.6[0x3c2fa78c80] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] > > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] > > /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] > > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] > > /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] > > /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] > > /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] > > /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] > > /usr/bin/perl(main+0x154)[0x400e74] > > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] > > [snipped] > > >
Re: OpenSSL version 3.0.0-alpha1 build failed
This appears to be a bug in perl. You have a very old version of perl (the oldest we support is 5.10.0). It's probably worth trying to upgrade it. Matt On 30/04/2020 22:12, Ken Goldman wrote: > My build failed with the below. > > x86_64 Linux kernel 2.6.32 > RHEL 6.7 > Perl 5.10.1 > > Everything through 1.1.1e was successful. > > ~~ > > > ./config > Operating system: x86_64-whatever-linux2 > Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 > Using os-specific seed configuration > *** glibc detected *** /usr/bin/perl: double free or corruption (out): > 0x02a401e0 *** > === Backtrace: = > /lib64/libc.so.6[0x3c2fa75dee] > /lib64/libc.so.6[0x3c2fa78c80] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] > /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] > /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] > /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] > /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] > /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] > /usr/bin/perl(main+0x154)[0x400e74] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] > [snipped] >
OpenSSL version 3.0.0-alpha1 build failed
My build failed with the below. x86_64 Linux kernel 2.6.32 RHEL 6.7 Perl 5.10.1 Everything through 1.1.1e was successful. ~~ ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 Using os-specific seed configuration *** glibc detected *** /usr/bin/perl: double free or corruption (out): 0x02a401e0 *** === Backtrace: = /lib64/libc.so.6[0x3c2fa75dee] /lib64/libc.so.6[0x3c2fa78c80] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] /usr/bin/perl(main+0x154)[0x400e74] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] [snipped]
