s_client/s_server trouble

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

s_client/s_server trouble

Jan Just Keijser-2
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Jan Just Keijser-2
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Jakob Bohm-7
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Viktor Dukhovni
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Jakob Bohm-7
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Viktor Dukhovni
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
Reply | Threaded
Open this post in threaded view
|

Re: s_client/s_server trouble

Jan Just Keijser-2
In reply to this post by Viktor Dukhovni
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