Steve:
Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH' is a
success,
and also just -cipher 'DHE-RSA-AES256-SHA' to make it as small as possible.
So looks like a bug with nss 3.15 or with OpenJDK 1.7.0_45 calling it with a
ClientHello somewhere in size between the failing 321
On Tue, Dec 17, 2013, Porter, Andrew wrote:
> That server response (15 03 03 00 02 02 50) has byte 0 = SSL3_RT_ALERT and
> byte 5 = SSL3_AL_FATAL so that means it hated the s_client TLS 1.2
> ClientHello, ja?
>
Yes though the "internal error" alert suggests it might not be OpenSSL's
fault.
>
Hi,
I realise the 1.0.0 to 1.0.1 transition happened some time ago, but it only
hit Centos recently (with the 6.5 release). Some of our code broke, and while
I suspect the problem is too low-level / detailed for anyone to say anything
useful, I thought I better ask, just in case... (if you can h
On 17 December 2013 18:11, Porter, Andrew wrote:
> We've into a problem with a native x86/Linux app of ours - linked
> statically with vanilla openssl-fips-2.0.2 and openssl-1.0.1e we've
> built - trying to connect to our Java app when it is running under
> the latest OpenJDK 1.7.0_45 on RedHat 6.
I should have also said that this is called by X509_REQ_sign.
So, in short, the EVP_MD.digest atrtibute is not used to do signing when
passed to X509_REQ_sign.
You know, it's only writing that the word "digest" has jumped out at me. Is
that even the right place for doing signing? Or is it mean
On Tue, Dec 17, 2013, andrew cooke wrote:
>
> I should have also said that this is called by X509_REQ_sign.
>
> So, in short, the EVP_MD.digest atrtibute is not used to do signing when
> passed to X509_REQ_sign.
>
> You know, it's only writing that the word "digest" has jumped out at me. Is
>
Yes, that's how my more recent engine-based code works. Maybe the best thing
is to merge those two code bases and get rid of this old stuff. Thanks,
Andrew
On Tue, Dec 17, 2013 at 07:56:46PM +0100, Dr. Stephen Henson wrote:
> On Tue, Dec 17, 2013, andrew cooke wrote:
>
> >
> > I should have
That server response (15 03 03 00 02 02 50) has byte 0 = SSL3_RT_ALERT and
byte 5 = SSL3_AL_FATAL so that means it hated the s_client TLS 1.2 ClientHello,
ja?
Tried the non-FIPS 1.0.1e openssl s_client I had a build of, same error so the
FIPS code doesn't seem to be the issue.
When I add -no_tls
OK, so I'm seeing the same symptoms for a different reason: we're using
statically linked
openssl 1.0.1e & fips-2.0.2 (the full one, not the ecp version with curves
removed)
we've built ourselves from openssl.org downloads so this is either a bug in
openssl or
nss (3.15.1 on CentOS 6.5, 3.15.2 o
Argh, OK, the attribute is called sign. So it's correct, I just had the wrong
name in my notes. Andrew
On Tue, Dec 17, 2013 at 03:51:04PM -0300, Andrew Cooke wrote:
>
> I should have also said that this is called by X509_REQ_sign.
>
> So, in short, the EVP_MD.digest atrtibute is not used to
We've into a problem with a native x86/Linux app of ours - linked
statically with vanilla openssl-fips-2.0.2 and openssl-1.0.1e we've
built - trying to connect to our Java app when it is running under
the latest OpenJDK 1.7.0_45 on RedHat 6.5 or OpenSUSE v13.1:
the native app logs
SSL_connect: tls
Hi,
I am using libcurl and OpenSSL to communicate with various webservers, most of
which require client authentication. I am having trouble connecting to one
server that requires TLSv1.2. After the server has sent a Certificate Request,
OpenSSL sends up the client cert (I think) and the serve
12 matches
Mail list logo
