You would have to ignore some initial certificate info output but some
variation on
echo "GET /version" | openssl s_client -connect test.example.com -crlf -ign_eof
-quiet
would be as pure OpenSSL as you can get…
Andrew
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
See the error message about looking at the FAQ? Here it is:
https://www.openssl.org/docs/faq.html#USER1
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
aakash.ku...@orange.com
Sent: Sunday, October 07, 2018 22:51
To: openssl-users@openssl.org
Cc:
My "make test" for today's 1.0.2n release is getting an error at the very last
(I think)
"test_bad_dtls" step. This is FIPS-enabled, built with the 2.0.12 FIPS module.
With the
Previous 1.0.2m release the "test_bad_dtls" step silently completed but with
1.0.2n I get:
test_bad_dtls
Yes, 2.0.16 and 1.0.2l as per https://www.openssl.org/source/
But there will be a 1.0.2m out on Thursday.
Andrew
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Karyn Ulriksen
Sent: Tuesday, October 31, 2017 14:51
To: openssl-users@openssl.org
Subject:
Support for DTLS 1.2 was one of the major changes from 1.0.1 to 1.0.2, see
https://www.openssl.org/news/openssl-1.0.2-notes.html
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Salz, Rich via openssl-users
Sent: Wednesday, September 06, 2017 06:49
To:
Thanks Steven for pointing me in the right direction: when I switched to an
EC/ECDSA key for tomcat then openssl could connect using
ECDHE-ECDSA-AES256-GCM-SHA384.
But only after installing the unlimited strength policy files on the server,
with the defaults the best was
Running sslscan against Tomcat 8.0.43 / Oracle Java 8u121 and a Tomcat
server.xml containing
ciphers="HIGH:!aNULL:!RC4:!MD5:@STRENGTH"
shows the strongest cipher is
ECDHE-RSA-AES128-GCM-SHA256
Installing the Java unlimited strength policy files increases this to
ECDHE-RSA-AES256-GCM-SHA384
If that version string was printed by a Linux system-provided "openssl" command
you'd be best off downloading the system-specific source packages. To make your
best guess at building it manually yourself from original source:
(a) your old OpenSSL source here:
./config works just fine for me on a SLES 11.3 z/Linux, and yes it sets
PLATFORM to "linux64-s390x" in MAKEFILE
Andrew
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Thomas Francis, Jr.
Sent: Friday, May 12, 2017 12:55
To:
There may be other solutions but here are two I've used:
(1) Upgrade the Java the server uses to a recent Java 8. It should run fine.
The product I work in is built with the Java 6 development kit but runs without
any problems on Java 6 - 8.
(2) Update the server Java 6 to the latest version
Multiple versions of OpenSSL can, with an additional source package (the
OpenSSL FIPS module) be built by you to be 140-2 compliant. See
http://openssl.com/fips/
for more info.
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Vikram Kamaraj - ERS, HCL Tech
Sent:
I'm building today's 1.0.1s release with FIPS 2.0.8 and "make test" is failing
at the test_ssl step, it correctly says "test ssl3 is forbidden in FIPS mode"
but then stops testing with the output
47323521796064:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips
Building today's 1.0.1s release with FIPS 2.0.8 failed tests for me at the
test_ssl step with a not-surprising "test ssl2 is forbidden in FIPS mode".
Tests ran fine for 1.0.1r a couple of weeks ago.
Is there a simple way for me to fix this?
Andrew
--
openssl-users mailing list
To unsubscribe:
Download OpenSSL 0.9.8f and install it somewhere it stays separate from the
RHEL system package, say /opt/openssl098f. Building it would be something like
this:
./config --prefixdir=/opt/openssl098f --openssldir=/opt/openssl098f
make
make install
Then whatever you have to do for OpenSSH to
The version 1.0.0-fips indicates a build of OpenSSL that used both the 1.0.0
source and one (can't tell which) of the openssl-fips source packages.
If you're seeing that version number printed out by the openssl command on
your system you probably need to get the source from the operating
For jars you need to use the jarsigner utility in the Java Development Kit
(JDK). This can access certs in the Windows personal and root certificate
stores, see
http://www.oracle.com/technetwork/articles/javase/security-137537.html
using Windows-MY or Windows-ROOT for the KeyStore
In general for cross-compiling you run ./Configure with various options,
perhaps after setting up some environment variables like CC to point to your
development tools. For example, to build Linux 32-bit on my 64-bit build
machine I start with:
./Configure linux-elf -m32 plus --openssldir= and
The make test step for FIPS-enabled 1.0.1i is failing for me in the ectest
(elliptic curves) section with:
SEC2 curve secp160r1 -- Generator:
x = 0x4A96B5688EF573284664698968C38BB913CBFC82
y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order ok
Take a look at the file INSTALL in the top level of the source package to learn
what development tools are required and what the basic procedure is and it
might be useful to do a build on a standard platform like a Linux virtual
machine to see how it works.
From:
The openssl source package includes a generic server (s_server) and client
(s_client).
My first suspect when something has a memory leak with SSL connections only is
to check whether SSL contexts returned by SSL_new() always get cleaned up later
by calling SSL_free()...
Andrew
-Original
(a) please don't spam all of the lists. The openssl-users is sufficient
(b) you got a reply to your question yesterday. Check your email and the Gmail
spam folder.
- Andrew
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Arun Kumar
Sent: Tuesday,
Florian:
It would be great to have a self-contained reproducer, so that
we can test this before we enable the NSS-backed crypto
provider in OpenJDK again. Can you use official channels for this?
I can provide you with the x86_64 openssl 1.0.2 utility I built yesterday as
the client plus an
Weimer
Sent: Thursday, December 19, 2013 9:09 AM
To: openssl-users@openssl.org
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On 12/17/2013 07:11 PM, Porter, Andrew wrote:
and the Java app throws the exception:
PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
Can you provide
-openssl-users On Behalf Of Porter, Andrew
Sent: Tuesday, December 17, 2013 17:53
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
Steve:
If you try OpenSSL 1.0.2 you can customise the signature algorithms and
supported curves using a command line option.
Erm, how? The ssltest.c and ssl_conf.c source files suggest -named_curve or
-curves as a possibilities, but trying to use them with openssl s_client just
gets me
The s_client and s_server utilities can use the new SSL_CONF API in 1.0.2,
see:
http://www.openssl.org/docs/ssl/SSL_CONF_cmd.html#SUPPORTED_COMMAND_LINE_COMMANDS
The -sigalgs and -curves options should do the trick.
I did try -curves before and failed, but I must have been tripped up by
Maybe just a co-incidence, but the sect571r1 curve is the only binary curve
in your list- the others are all prime curves. Maybe it doesn't like binary
curves?
Yes, if any binary curve (sect571r1, sect571k1, sect409k1, sect409r1,
sect283k1, sect283r1, sect239k1, sect233k1, sect233r1,
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:
-openssl-us...@openssl.org]
On Behalf Of Matt Caswell
Sent: Tuesday, December 17, 2013 10:47 AM
To: openssl-users@openssl.org
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On 17 December 2013 18:11, Porter, Andrew andrew_por...@bmc.com wrote:
We've into a problem with a native x86
in hacking about with our own code, surely
disabling TLS can't be the right thing to do...
-Andrew
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Porter, Andrew
Sent: Tuesday, December 17, 2013 11:36 AM
To: openssl-users@openssl.org
interoperability issue?
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
From the User Guide for the OpenSSL FIPS Object Module v2.0, section 3.2:
note the ./config 'shared' option is forbidden by the terms of the validation
when building a FIPS validated module, but the fipscanister.o object module can
be used in a shared library.
-Original Message-
From:
: Wednesday, March 27, 2013 3:02 PM
To: openssl-users@openssl.org
Cc: Porter, Andrew
Subject: Re: Troubles building FIPS-enabled OpenSSL on s390x
On 03/27/2013 03:26 PM, Porter, Andrew wrote:
After successfully building the combination of openssl-fips-2.0.2 and
openssl-1.0.1e on Intel Linux I am
After successfully building the combination of openssl-fips-2.0.2 and
openssl-1.0.1e on Intel Linux I am trying to do the same on mainframe Linux,
64-bit SuSE 10.2 in my case.
When I unpack openssl-fips-2.0.2 and do ./config; make it fails with
*** No rule to make target `s390xcap.o', needed
34 matches
Mail list logo
