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. >
