Hello,
Can s_client be used to send additional certificates (i.e. certificates that
are not part of the chain for the current connection)
I am trying to do the following (pseudocode):
s_client -key myclient.key -cert myclient.cer -verifyCAfile expectedserverCA
-connect server:port
:
openssl s_client -connect data.reversinglabs.com:443 -tls1_2
-servername data.reversinglabs.com
Check your server setup and ensure that a default virtual host has been
defined.
Mark Hack
On Tue, 2022-05-17 at 15:55 -0400, Geek Geek wrote:
> I run into the following issue when I use openssl 1.0
I run into the following issue when I use openssl 1.0.2k (amazon linux2)
to check the connection.
[ec2-user@ip-172-31-29-28 ~]$ openssl s_client -connect
data.reversinglabs.com:443 -tls1_2
CONNECTED(0003)
139994515941280:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
On Fri, Mar 11, 2022 at 04:40:24PM -0800, Edward Tsang via openssl-users wrote:
> Does verify_ip supports leftmost wildcard?
I am not aware of any RFC specifying wildcard matching in iPAddress
X.509 SANs, and no such feature is implemented in OpenSSL.
The SAN syntax is raw binary data in network
Hi
Does verify_ip supports leftmost wildcard?
I know that hostname does for SAN and CN. But ip address seems to only
support exact match including the port?
Is that observation correct?
What does it take for verify_ip to support leftmost wildcard matching just
like DNS hostname?
Thanks
- Forwarded Message - From: Zlatko Vrastic To:
"openssl-users@openssl.org" Sent: Friday, October
22, 2021, 03:25:10 PM GMT+2Subject: openssl s_client privatekey engine pkcs11 -
no SSL_connect:SSLv3/TLS write certificate verify
When using
openssl s_client .. -keyf
> On 30 Sep 2021, at 3:34 pm, nate wrote:
>
>> $ openssl s_client -showcerts \
>>-connect bad_server_name:443 \
>>-servername bad_server_name 2>/dev/null |
>>openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
>>openssl pkcs7 -prin
On 2021-09-30 11:36, Viktor Dukhovni wrote:
Ah, you also need to add "-showcerts" to s_client and best to separate
stdout and stderr in order to avoid confusion due to error text leaking
through, sender stderr to /dev/null:
$ openssl s_client -showcerts \
-connect bad_serve
On Thu, Sep 30, 2021 at 11:26:14AM -0700, nate wrote:
> > This is *not* the correct way to see all the expiration dates in the
> > chain. It will show only the leaf certificate dates. The right
> > incantation is:
> >
> > $ openssl s_client -connect b
enssl s_client -connect bad_server_name:443 -servername
bad_server_name | openssl x509 -noout -dates
This is *not* the correct way to see all the expiration dates in the
chain. It will show only the leaf certificate dates. The right
incantation is:
$ openssl s_client -connect bad_server_nam
On Thu, Sep 30, 2021 at 09:43:54AM -0700, nate wrote:
> If I run this on OpenSSL 1.0.2g (Ubuntu 16.04)
>
> openssl s_client -connect bad_server_name:443 -servername bad_server_name
>
> I get at the end a clear: Verify return code: 10 (certificate has expired)
This is becaus
On 2021-09-30 10:12, nate wrote:
That is interesting and explains some things. One more Q for you, this
app
Oops sorry no more Qs, I was going to write one then I realized that
OpenSSL
appends the OS certs on top of the custom CA cert file which I wasn't
expecting, updated my email forgot to
after further testing even when telling openssl s_client
to look at a specific CA file it looks at it, and also looks at the OS
stuff as well if there is a CA with the OS and not in the custom CA file
(which has about 113 CAs in it).
Not a big deal will all be fixed when they update the cert.
t
rding checking of the CA cert.
If I run this on OpenSSL 1.0.2g (Ubuntu 16.04)
openssl s_client -connect bad_server_name:443 -servername bad_server_name
(the server in question uses SNI)
I get at the end a clear:
Verify return code: 10 (certificate has expired)
If I run on the same OpenSSL:
op
er is managed by someone else so they are
trying to
get them to fix it.
While investigating I saw some strange behavioral differences between
OpenSSL 1.0 and
1.1 specifically regarding checking of the CA cert.
If I run this on OpenSSL 1.0.2g (Ubuntu 16.04)
openssl s_client -connect bad_server_nam
Hi All,
Sorry, send to missing.
Patrice.
Message transféré
Sujet : Re: openssl s_client connection fails
Date : Wed, 18 Nov 2020 14:46:45 +
De :Matt Caswell
Pour : Patrice Guérin
On 18/11/2020 14:33, Patrice Guérin wrote:
Hello Matt,
Thank you for
Hi All,
Sorry, send to missing.
Patrice.
Message transféré
Sujet : Re: openssl s_client connection fails
Date : Wed, 18 Nov 2020 11:40:33 +
De :Matt Caswell
Pour : openssl-users@openssl.org
On 18/11/2020 11:24, Patrice Guérin wrote:
3072988928:error
and could be due to any number of issues. Do
you have access to the server in question? If so there may be more clues
in the server logs that might explain it.
> Does anybody have an idea on what's going wrong ?
One thing that springs to mind that often goes wrong is SNI handling.
s_clie
Hello,
I experience the following on Linux Debian 9 (openssl 1.1.0l) :
When using openssl s_client to connect on a site, I get the following
CONNECTED(0003)
3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:../ssl/record/rec_layer_s3.c:1407:SSL alert
John Jiang wrote:
> Hi, Can I specify multiple certificates for tools s_server and
> s_client? I need to check the certificate selection with
> certificate_authorities.
> And it looks s_server has no option for certificate_authorities,
> however s_client has
Hi,
Can I specify multiple certificates for tools s_server and s_client?
I need to check the certificate selection with certificate_authorities.
And it looks s_server has no option for certificate_authorities, however
s_client has -requestCAfile for that extension.
Best regards,
John
On 27/04/2020 09:07, FooCrypt wrote:
> Hi
>
> Im just testing openssl s_client against a server IP and it appears to be
> failing with the following. :
>
> openssl s_client -showcerts -servername ${Site} -connect ${Site}:443 -debug
>
> OpenSSL 1.0.2u 20 Dec 2019
Hi
Im just testing openssl s_client against a server IP and it appears to be
failing with the following. :
openssl s_client -showcerts -servername ${Site} -connect ${Site}:443 -debug
Hiya,
On 11/11/2019 16:50, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
>> Behalf Of Stephen Farrell Sent: Monday, November 11, 2019 09:53
>>
>> I'm seeing some errors from valgrind when running s_client from a
>>
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Stephen Farrell
> Sent: Monday, November 11, 2019 09:53
>
> I'm seeing some errors from valgrind when running s_client
> from a clean build from the tip. (Details of that below.)
Have you re
Hiya,
I'm seeing some errors from valgrind when running s_client
from a clean build from the tip. (Details of that below.)
In another build, (for ESNI), when I do a GCM encrypt and
then read the tag, it looks like the error is coming from
some sha256 assembler code:
==27027== Uninitia
Hello
I see strange behavior of openssl s_client in case of post-handshake
authorization with PSK
command lines:
apps/openssl s_client -connect localhost:4433 -tls1_3 -4 -ciphersuites
TLS_AES_128_GCM_SHA256 -psk $PSK -enable_pha -cert cert.pem -key key.pem
-trace
apps/openssl s_server -accept
9 at 9:56 PM Hubert Kario wrote:
> > On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> > > Is it possible to check if peer implements middlebox compatibility by
> > > s_server/s_client?
> > > It looks the test tools don't care this point.
> > &
atibility by
> > s_server/s_client?
> > It looks the test tools don't care this point.
> > For example, if a server doesn't send change_cipher_spec after
> > HelloRetryRequest, s_client still feels fine.That's not bad. But can I
> > setup these tools to ch
On Tuesday, 26 February 2019 07:22:52 CET John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> He
On 26/02/2019 06:22, John Jiang wrote:
> Is it possible to check if peer implements middlebox compatibility by
> s_server/s_client?
> It looks the test tools don't care this point.
> For example, if a server doesn't send change_cipher_spec after
> HelloRetryRequ
Is it possible to check if peer implements middlebox compatibility by
s_server/s_client?
It looks the test tools don't care this point.
For example, if a server doesn't send change_cipher_spec after
HelloRetryRequest, s_client still feels fine.That's not bad. But can I
setup these
Sep 26, 2018, at 9:19 PM, 이영주 wrote:
> >
> > I wonder why master-key is revealed in plaintext in the results below.
> > (used command : Openssl s_client -connect host:port)
>
> Because s_client is a debugging tool, and a source of example code
> that demonstrates many e
> On Sep 26, 2018, at 9:19 PM, 이영주 wrote:
>
> I wonder why master-key is revealed in plaintext in the results below.
> (used command : Openssl s_client -connect host:port)
Because s_client is a debugging tool, and a source of example code
that demonstrates many elaborate feature
Hello. I am a person working in Korea.
I have a question.
I wonder why master-key is revealed in plaintext in the results below.
(used command : Openssl s_client -connect host:port)
(skip)
SSL-Session
* 1. Why does s_server need option "-servername"?
For debugging, so that you can test that clients are sending the right SNI
extension and properly handling the TLS error when they don’t.
* 2. It looks options -servername and -alpn cannot work together.
Yes, kind-of. Th
I just tried s_server, and its logs included something like "Hostname in
TLS extension".
But I still have a couple of puzzles.
1. Why does s_server need option "-servername"?
I supposed only s_client needs this option.
With my test, if only s_client specified "-server
,
> The following is my OpenSSL version info,
> OpenSSL 1.1.0f 25 May 2017
>
> I supposed the below command can give me some SNI info, but nothing was
> found.
> openssl s_client -debug -tlsextdebug -msg -connect -servername
> < /dev/null | grep "server name"
>
The “server name” is something that the client sends to the server.
This allows a single host to server multiple “virtual hosts”
From: John Jiang
Reply-To: openssl-users
Date: Sunday, November 26, 2017 at 9:59 PM
To: openssl-users
Subject: [openssl-users] How to get SNI info from s_client
Hi,
The following is my OpenSSL version info,
OpenSSL 1.1.0f 25 May 2017
I supposed the below command can give me some SNI info, but nothing was
found.
openssl s_client -debug -tlsextdebug -msg -connect -servername
< /dev/null | grep "server name"
But I found SNI extension with Wi
I am using openssl command line client (s_client) and wireshark to identify
the behaviour of a server that enforces secure renegotiation for client
certificate verification. Since the Master-Key is printed along with
SSL-Session information, I am able to use it in wireshark to decrypt the
messages
> On Feb 5, 2017, at 3:26 PM, Walter H. via openssl-users
> wrote:
>
> openssl s_client -connect mailhost:25 -starttls smtp
>
> displays this:
>
> CONNECTED(0003)
> depth=0 OU = Domain Control Validated, CN = ...
> verify error:num=20:unable to get loc
Hello,
openssl s_client -connect mailhost:25 -starttls smtp
displays this:
CONNECTED(0003)
depth=0 OU = Domain Control Validated, CN = ...
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = ...
verify error:num=27
Hi Salz,
Thanks for your reply and clarification.
Best Regards,
Mofassir
On Wednesday, 9 November 2016 1:48 AM, "Salz, Rich"
wrote:
#yiv7868915218 -- filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2
4;}#yiv7868915218 p.yiv7868915218MsoNormal, #yiv7868915218
li.yiv7868915218M
> On Nov 8, 2016, at 4:26 AM, Erwann Abalea wrote:
>
> The root certificate is not expected to be sent by the server, as it already
> needs to be known and trusted by the client.
> However, you’re free to configure your server to send it, for debugging or
> informational purposes.
A root CA c
Haque
mailto:mofassir_ha...@yahoo.com>> a écrit :
Hi All,
The output of "openssl s_client -showcerts -connect ..." command dose not
include Root certificate (which is expected behaviour). However, is it possible
to configure Server to return Root CA certificate also ?
Than
Yes, just put the entire chain in the server’s PEM file.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
In message
<0675024e00e342d9a8c668fd10791...@usma1ex-dag1mb1.msg.corp.akamai.com> on Sun,
16 Oct 2016 20:12:02 +, "Salz, Rich" said:
rsalz> Use the –nocommands flag.
Another way, which also works with OpenSSL versions before 1.1.0, is
-ign_eof
Cheers,
Richard
--
Richard Levitte
Use the –nocommands flag.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Hello,
I've come across something strange. When using openssl s_client and trying to
send B (uppercase only) as the first character on any line it causes a
heartbeat to be sent. Is this a bug or a feature? Any way to escape it to
send the uppercase B without sending the heartbeat?
Than
Hello,
I've come across something strange. When using openssl s_client and trying to
send B (uppercase only) as the first character on any line it causes a
heartbeat to be sent. Is this a bug or a feature? Any way to escape it to
send the uppercase B without sending the heartbeat?
Than
> A Wireshark trace reveals that the client shuts down the handshake
> connection with the reason ‘Unknown CA’.
> So if the client knows that the cert is self-signed as indicated by the debug
> logs, why would it issue the above reason for failure when it doesn’t need to
> know the CA?
You st
sl-users-boun...@openssl.org] On Behalf Of
Matthew Donald
Sent: July-01-16 12:09 AM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] self-signed certificate won't work in
my app but works with s_client
"error 18:self signed certificate" is the expected result if you a
onnect to an in-house tool but I'm
> getting the error "error 18:self signed certificate". Despite this error
> when I run my app (essentially client3), when I use s_client with the very
> same credentials...it works.
>
> I suspect that it has something to do with the ssl/
quot;. Despite this error when I run my app
(essentially client3), when I use s_client with the very same credentials...it
works.
I suspect that it has something to do with the ssl/tls api combination that I
use in my 'client3' app.
Here's the command and output for s_client th
-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 cod
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,
&g
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
; 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 "-accep
vious 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
e 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
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/o
usch wrote:
Hello Viktor,
from what I can see there is no number wether in the URL nor on the page
itself, that shows this docu is meant for the upcoming version 1.1.0.
Though it's clear now.
Thanks a lot for the hint!
Cheers
Markus
Von: Viktor Dukhovni
On Apr 8, 2016, at 2:52 AM,
enssl-users-boun...@openssl.org] Im Auftrag von
Viktor Dukhovni
Gesendet: Freitag, 8. April 2016 09:23
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] Regarding s_client -proxy option
> On Apr 8, 2016, at 2:52 AM, Markus Reusch wrote:
>
> I am in search of the –proxy optio
> On Apr 8, 2016, at 2:52 AM, Markus Reusch wrote:
>
> I am in search of the –proxy option for s_client. According to
> https://www.openssl.org/docs/manmaster/apps/s_client.html it should be
> implemented
That's the documentation for the upcoming 1.1.0 release. The relat
Hello all,
I am in search of the -proxy option for s_client. According to
https://www.openssl.org/docs/manmaster/apps/s_client.html it should be
implemented, but when compiling the latest stable version 1.0.2g I just get the
message, that -proxy for s_client is an unknown option.
Searching all
Try:
openssl s_client -crl_check_all ...
Works! Great, thanks for the hint Viktor.
Just recognized, that the manpage lists the "crl_check_all" options right after the
"crl_check", which i used... >_<
Using the crl_check_all it also complains about a missing crl now,
I am a bit wary that someone started adding certificates to the trust
store based on this new behavior not realizing that some is using it
with a different semantic. Maybe a note ("other software may not do the
same") would be appropiate.
I can't find the entry for this in CHANGES, though.
PS:
is correctly shown as
> revoked, so the content of the verifydir is fine I think.
This is not a check of the intermediate certificate as an actual
intermediate in a chain, this only checks it as a leaf certificate.
Your entire chain is just:
root ---> revokedIntermediate
> Someh
>I am testing with revoking certificates.
>
>My PKI has a root and 2 intermediates, which then sign server and
client certificates
>My test environment consists of a s_client and a s_server referencing
the corresponding files and a verifydir with c_rehased files.
>TLS connections
On Fri, Mar 11, 2016 at 06:16:45AM +0100, Jakob Bohm wrote:
> >They are not trust-anchors, so absent an issuer higher up, they
> >are not sufficient to establish a "chain of trust", unless the
> >application enables "partial chain" support.
>
> Ok, that reverses the fundamental assumption behind a
On 11/03/2016 03:27, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:
Well, no, 1.0.2 uses the trust store not only for trust-anchors,
but also as a capricious source of intermediate certificates, whose
behaviour varies depending on whether the peer supplied sa
On Thu, Mar 10, 2016 at 11:14:12PM -0500, Jeffrey Walton wrote:
> > However, in 1.0.x (more bug than feature) basic constraints, key
> > usage constraints and EKU constraints, which are applied to
> > intermediate certificates provided by the peer, are not applied
> > when the intermediate certifi
>> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
>> >but also as a capricious source of intermediate certificates, whose
>> >behaviour varies depending on whether the peer supplied same said
>> >certificates on the wire or not. I expect to improve the capricious
>> >behaviour.
On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:
> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
> >but also as a capricious source of intermediate certificates, whose
> >behaviour varies depending on whether the peer supplied same said
> >certificates on the wire or
On 11/03/2016 02:23, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
I am arguing that:
- 1.0.x behavior should not be changed, as it would violate the
principle of least surprise for a "security update" to change
semantics.
The odd 1.0.x behaviour l
On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
> I am arguing that:
>
> - 1.0.x behavior should not be changed, as it would violate the
> principle of least surprise for a "security update" to change
> semantics.
The odd 1.0.x behaviour leads to periodic email to openssl-securi
On 11/03/2016 01:18, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:
Your reply below is a perfect illustration of the expected confusion.
Sorry, I disagree. The 1.1.0 changes fix various shortcomings that
may well also be addressed in a future 1.0.2 update.
On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:
> Your reply below is a perfect illustration of the expected confusion.
Sorry, I disagree. The 1.1.0 changes fix various shortcomings that
may well also be addressed in a future 1.0.2 update.
The net effect is more consistent behaviour
On 10/03/2016 23:41, Viktor Dukhovni wrote:
On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
This is changing in OpenSSL 1.1.0, and may yet change in a future
OpenSSL 1.0.2 update. Only the trust-anchor (top-most certificate
>from the trust-store) is not checked for expiration or r
On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
> >This is changing in OpenSSL 1.1.0, and may yet change in a future
> >OpenSSL 1.0.2 update. Only the trust-anchor (top-most certificate
> >from the trust-store) is not checked for expiration or revocation
> >in OpenSSL 1.1.0.
> >
> >In
On 10/03/2016 23:06, Viktor Dukhovni wrote:
On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:
Any ideas what i could be doing wrong?
Make sure the intermediary is not included in the "CA storage"
(hashed or single file) used by the client. Anything in that
storage is considered vali
On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:
> >Any ideas what i could be doing wrong?
>
> Make sure the intermediary is not included in the "CA storage"
> (hashed or single file) used by the client. Anything in that
> storage is considered valid and not checked for revocation or
On 10/03/2016 20:11, mich...@secure-mail.biz wrote:
Hey openssl users,
I am testing with revoking certificates.
My PKI has a root and 2 intermediates, which then sign server and
client certificates
My test environment consists of a s_client and a s_server referencing
the corresponding files
Hey openssl users,I am testing with revoking certificates.My PKI has a root and 2 intermediates, which then sign server and client certificatesMy test environment consists of a s_client and a s_server referencing the corresponding files and a verifydir with c_rehased files.TLS connections work
On 04-01-16 11:11, Kaushal Shriyan wrote:
Hi,
what does the letter 's' signify in *s_client* in the command "openssl
s_client -servername test.example.com <http://test.example.com> -connect
test.example.com:443 <http://test.example.com:443> -showcerts" ?
The
Hi,
what does the letter 's' signify in *s_client* in the command "openssl
s_client -servername test.example.com -connect test.example.com:443
-showcerts" ?
Regards,
Kaushal
___
openssl-users mailing list
To unsubscribe: htt
On Tue, Dec 01, 2015 at 05:33:41PM -0600, Benjamin Kaduk wrote:
> On 12/01/2015 05:28 PM, Nounou Dadoun wrote:
> > Getting an unexpected result, does the no_tls1 option for s_client mean
> > "don't use tls1" (and everything else is ok) or does it mean "don'
ssage-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Benjamin Kaduk
Sent: Tuesday, December 01, 2015 3:34 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] s_client -no_tls1 option
On 12/01/2015 05:28 PM, Nounou Dadoun wrote:
> Getting an unexpecte
On 12/01/2015 05:28 PM, Nounou Dadoun wrote:
> Getting an unexpected result, does the no_tls1 option for s_client mean
> "don't use tls1" (and everything else is ok) or does it mean "don't use tls1
> or tls1.1 or tls1.2"? I expected the former but I&#x
Getting an unexpected result, does the no_tls1 option for s_client mean "don't
use tls1" (and everything else is ok) or does it mean "don't use tls1 or tls1.1
or tls1.2"? I expected the former but I'm observing the latter! (The man page
doesn't go in
> It would thus be useful for s_server (and if applicable
> s_client) to accept the "-binary" option (already provided by the cms/smime
> commands), to turn off this behavior and provide a clean data pass through
> to/from the other end.
This
On 2 November 2015 at 15:36, Richard Moore wrote:
>
>
> On 2 November 2015 at 15:33, Jakob Bohm wrote:
>
>> On 02/11/2015 16:13, Richard Moore wrote:
>>
>> There have always been special commands making s_client unsuitable for
>> this usage - for example R fo
On 2 November 2015 at 15:33, Jakob Bohm wrote:
> On 02/11/2015 16:13, Richard Moore wrote:
>
> There have always been special commands making s_client unsuitable for
> this usage - for example R followed by a newline will renegotiate, and Q
> will quit. According to the do
On 02/11/2015 16:13, Richard Moore wrote:
There have always been special commands making s_client unsuitable for
this usage - for example R followed by a newline will renegotiate, and
Q will quit. According to the docs these can be disabled by -quiet
and -ign_eof though I've never tested
There have always been special commands making s_client unsuitable for this
usage - for example R followed by a newline will renegotiate, and Q will
quit. According to the docs these can be disabled by -quiet and -ign_eof
though I've never tested that myself.
Cheers
Rich.
On 2 November 20
As with most other "apps" in the openssl binary, the s_server
and s_client commands are useful for multiple purposes:
1. As debug tools
2. As a way to do one-off operations without writing any
code.
3. As back ends for small programs written in scripting
languages that cannot r
On Debian and Macports, the script below returns "Verify return code:
0 (ok)". Effectively, it claims Google's CA is certifying Microsoft
properties.
Some folks claim this is expected behavior. s_client(3) does not
discuss the expected behavior, so I'm not sure what should be
nssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Michael Wojcik
Sent: Thursday, December 11, 2014 12:08 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Using s_client under z/OS installation
A quick look at apps/s_client.c in the 1.0.1j sources suggests that it
[mailto:openssl-users-boun...@openssl.org] On Behalf Of
Savino, Victor
Sent: Thursday, December 11, 2014 10:53
To: 'openssl-users@openssl.org'
Subject: [openssl-users] Using s_client under z/OS installation
I am trying to use the s_client feature to retrieve certificates from other
SMPT servers. Th
1 - 100 of 322 matches
Mail list logo
