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 O
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: osf-cont...@openssl.o
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
../util/shlib
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: [openssl-users
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: openssl-users@op
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 ECDHE-ECDSA-AES128-GCM-
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
s
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:
https://www.openssl.org/source/old/
./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: openssl-users@op
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 of
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: Wedn
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
mode:ssl_lib.c:1720
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 poin
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 sy
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 param
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
l
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: owner-openssl-us...@openssl.org
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 M
(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, Jul
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 a
> 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, sect1
> 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 t
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
penssl-users@openssl.org
Subject: RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
> From: owner-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, a
On Behalf Of Florian 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_PARA
nssl.org
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS 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?
>
e 1.0.1e
s_client I don't see any point 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: Tues
inal Message-
From: owner-openssl-us...@openssl.org [mailto:owner-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 wr
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
>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
lfoundation.com]
Sent: 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.
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
