Re: [openssl-users] s_client/s_server trouble
Hi all, thanks for all the pointers - it was indeed a problem with the certificates. cheers, JJK / Jan Just Keijser On 19/05/16 18:19, Viktor Dukhovni wrote: On Thu, May 19, 2016 at 05:58:11PM +0200, Jakob Bohm wrote: What kind (and size) of keys are in your certificates? That sounds like the most likely issue. Perhaps that dhparam2049.pem does not actually contain a 2048-bit prime. I don't recall a floor on RSA key sizes in 1.0.1. The CHANGES file lists for 1.0.1q: *) Reject DH handshakes with parameters shorter than 1024 bits. [Kurt Roeckx] Otherwise, I don't see any enforcement of key size floors in 1.0.1. - I've set up a PKI with a ca.crt file and a server.crt/server.key keypair Not posting the certs makes it rather difficult to offer any help. - next , I run ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert server.crt -key server.key -dhparam dh2048.pem I don't see a "-accept 4433" in that command. - then, with s_client ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 127.0.0.1:4433 What's listening on "4433"? and I always end up with Verify return code: 21 (unable to verify the first certificate) If I either change s_server *or* s_client to use openssl 0.9.8 then the above commands work! With 0.9.8 s_client or s_server will be able to use the default CApath that is probably hashed with the 0.9.8-compatible hash algorithm, allowing either or both to construct a more complete chain, Likely the "ca.crt" you're using is not the (immediate?) issuer of the server certificate. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_client/s_server trouble
On Thu, May 19, 2016 at 06:31:54PM +0200, Jakob Bohm wrote:
> >With 0.9.8 s_client or s_server will be able to use the default
> >CApath that is probably hashed with the 0.9.8-compatible hash
> >algorithm, allowing either or both to construct a more complete
> >chain,
>
> Indeed, I find it very confusing that specifying -CAfile
> or -CApath to the various "apps" doesn't override the
> default value of the other, causing various tests to trust
> additional certificates not intended to be trusted by that
> test.
Yes, this is why I suggested additional controls to disable
the built-in paths in 1.1.0, which are now available:
NAME
s_client - SSL/TLS client program
SYNOPSIS
openssl s_client ...
[-CApath directory] [-CAfile filename] [-no-CAfile] [-no-CApath]
...
So for "total" control:
openssl s_client -CAfile cafile.pem -no-CApath ...
openssl s_server -CAfile cafile.pem -no-CApath ...
There is perhaps an oversight in s_server, because the -no-CA{file,path}
options don't seem to apply to the secondary context for SNI, which
always gets the default paths:
if ((!SSL_CTX_load_verify_locations(ctx2, CAfile, CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx2))) {
ERR_print_errors(bio_err);
}
That's likely surprising, and probably should be fixed for the final
release.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_client/s_server trouble
On 19/05/2016 18:19, Viktor Dukhovni wrote: With 0.9.8 s_client or s_server will be able to use the default CApath that is probably hashed with the 0.9.8-compatible hash algorithm, allowing either or both to construct a more complete chain, Indeed, I find it very confusing that specifying -CAfile or -CApath to the various "apps" doesn't override the default value of the other, causing various tests to trust additional certificates not intended to be trusted by that test. This hit me when I was trying to test yesterdays question about the numbering of certificate depths in error messages, as openssl verify kept accepting the test case despite using a CAfile without the relevant root. I had to pass in a dummy (empty) -CApath to get the expected results. Also, passing an empty file (such as /dev/null) for -CAfile causes an error, forcing the use of an irrelevant certificate file to trust an empty list of certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_client/s_server trouble
On Thu, May 19, 2016 at 05:58:11PM +0200, Jakob Bohm wrote: > What kind (and size) of keys are in your certificates? > > That sounds like the most likely issue. Perhaps that dhparam2049.pem does not actually contain a 2048-bit prime. I don't recall a floor on RSA key sizes in 1.0.1. The CHANGES file lists for 1.0.1q: *) Reject DH handshakes with parameters shorter than 1024 bits. [Kurt Roeckx] Otherwise, I don't see any enforcement of key size floors in 1.0.1. > > >- I've set up a PKI with a ca.crt file and a server.crt/server.key > > > keypair Not posting the certs makes it rather difficult to offer any help. > > >- next , I run > >> > >> ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert > >>server.crt -key server.key -dhparam dh2048.pem I don't see a "-accept 4433" in that command. > >>- then, with s_client > >> > >> ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect > >>127.0.0.1:4433 What's listening on "4433"? > >>and I always end up with > >> > >> Verify return code: 21 (unable to verify the first certificate) > >> > >>If I either change s_server *or* s_client to use openssl 0.9.8 then the > >>above commands work! With 0.9.8 s_client or s_server will be able to use the default CApath that is probably hashed with the 0.9.8-compatible hash algorithm, allowing either or both to construct a more complete chain, Likely the "ca.crt" you're using is not the (immediate?) issuer of the server certificate. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_client/s_server trouble
What kind (and size) of keys are in your certificates? That sounds like the most likely issue. On 19/05/2016 17:26, Jan Just Keijser wrote: Hi all, no one has seen this as well? I've seen other mails fly by on openssl-users after I posted this, yet no response to my query, nor to a previous mail I sent (about pkcs7). Should I file bug reports instead? Jan Just Keijser wrote: hi all, I've just run into something weird with openssl 1.0.1 and s_client+s_server: - I've downloaded and compiled a static version of openssl 1.0.1t on Linux - I've set up a PKI with a ca.crt file and a server.crt/server.key keypair - next , I run ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert server.crt -key server.key -dhparam dh2048.pem - then, with s_client ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 127.0.0.1:4433 and I always end up with Verify return code: 21 (unable to verify the first certificate) If I either change s_server *or* s_client to use openssl 0.9.8 then the above commands work! What am I missing here? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_client/s_server trouble
Hi all, no one has seen this as well? I've seen other mails fly by on openssl-users after I posted this, yet no response to my query, nor to a previous mail I sent (about pkcs7). Should I file bug reports instead? thx, JJK / Jan Just Keijser Jan Just Keijser wrote: hi all, I've just run into something weird with openssl 1.0.1 and s_client+s_server: - I've downloaded and compiled a static version of openssl 1.0.1t on Linux - I've set up a PKI with a ca.crt file and a server.crt/server.key keypair - next , I run ~/src/openssl-1.0.1t/apps/openssl s_server -CAfile ca.crt -cert server.crt -key server.key -dhparam dh2048.pem - then, with s_client ~/src/openssl-1.0.1t/apps/openssl s_client -CAfile ca.crt -connect 127.0.0.1:4433 and I always end up with Verify return code: 21 (unable to verify the first certificate) If I either change s_server *or* s_client to use openssl 0.9.8 then the above commands work! What am I missing here? TIA, JJK / Jan Just Keijser -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
