>wget --no-check-certificate https://bootstrap.pypa.io/get-pip.py
When I try this:
; ./apps/openssl s_client -connect bootstrap.pypa.io:443 -tls1_1
It fails. When I leave off the last flag, it connects via TLS 1.2
So that website does not support anything older than TLS 1.2, appare
Hi,
The command I'm running is:
wget --no-check-certificate https://bootstrap.pypa.io/get-pip.py
So in this particular case the host is: bootstrap.pypa.io. I was
trying to install the Python pip command.
Rob
On Mon, Apr 16, 2018 at 5:53 PM, Salz, Rich via openssl-users
wrote:
> You didn't ans
You didn't answer the question that was asked.
Which host?
On 4/16/18, 4:23 PM, "Rob Marshall" wrote:
Hi,
I built and installed OpenSSL 1.0.2n and I'm still seeing the problem.
I originally tried to build/install 1.1.0h but my goal was to
build/install an updated OpenSSH (
Hi,
When I do that I see, among other things:
...
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 9B63040F2D2F498F610A84E4A9D9017AF375772DFDDA760378666391A17C2C75
...
When I tried to force TLSv1.2 I got:
hostname:~ # wget --no-check-certificate -
It may be how the (probably somewhat outdated) version of wget is using the
openssl API. Try "openssl s_client -connect server:port", using the server and
port you're trying to get wget to connect to.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl
Hi,
I built and installed OpenSSL 1.0.2n and I'm still seeing the problem.
I originally tried to build/install 1.1.0h but my goal was to
build/install an updated OpenSSH (7.7.p1) and it wouldn't build with
that version and a straight 1.1.0 build failed. So I went with the
most recent 1.0.2 (in thi
On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote:
> Hi,
>
> It may not be relevant, but I'm running SLES 10 SP3 which is a very
> old version of the OS and I can't upgrade it due to some installed
> products. When I try to do a wget I'm seeing the error:
>
> OpenSSL: error:1407742E:SS
to upgrade the OS to put a newer version of OpenSSL on, though
you may have to build OpenSSL yourself.
From: openssl-users on behalf of Rob
Marshall
Sent: Monday, April 16, 2018 2:27:17 PM
To: openssl-users@openssl.org
Subject: [openssl-users] What does this error
Hi,
It may not be relevant, but I'm running SLES 10 SP3 which is a very
old version of the OS and I can't upgrade it due to some installed
products. When I try to do a wget I'm seeing the error:
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
alert protocol version
What does th
> Thank you! So it is the *client* that breaks the connection,
> and it is unhappy either about MiTM, or the encoding. I will
> check for both (though not much I can do about either).
Presumably you've added that cert to some trust store on the system in
question.
> On Apr 25, 2017, at 4:41 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
>Client objects to the server chain. Either does not trust the MiTM root
> CA, or
>is unhappy about its encoding (assuming tshark is not generating an FP
> warning).
>
> Thank you! So it is the *client* that b
> extensions: 4 items
> Extension (ns_cert_exts.comment)
> Extension Id: 2.16.840.1.113730.1.13
(ns_cert_exts.comment)
> BER Error: String with tag=22 expected
but c
> On Apr 25, 2017, at 3:17 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
> Secure Sockets Layer
> SSL Record Layer: Handshake Protocol: Client Hello
> Content Type: Handshake (22)
> Version: TLS 1.2 (0x0303)
> Length: 228
> Handshake Protocol: Client Hello
>
On 4/24/17, 7:26 PM, "openssl-users on behalf of Viktor Dukhovni"
wrote:
I get slightly annoyed when I take the time to help, but my response is
skimmed over and not read carefully. Upthread I said:
See my recent post:
https://www.spinics.net/lists/openssl-users/msg05623.html
> On Apr 24, 2017, at 7:11 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
>Please report tshark output, not an approximate rendition. In what
> direction
>is the alert sent?
>
> I’m using WireShark. The IP addresses on the Alert packet show local host as
> the source, and the proxy a
> I went through the capture between the app (local end) and the proxy. It
appears that the sequence is:
>
> ClientHello -> (from app to proxy, with a ton of cipher suites, including
0xc02f)
> <- ServerHello (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 –
present in ClientH
> On Apr 24, 2017, at 6:11 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
> I went through the capture between the app (local end) and the proxy. It
> appears that the sequence is:
>
> ClientHello -> (from app to proxy, with a ton of cipher suites, including
> 0xc02f)
> <- ServerHello
> Handshake failed
>
> The SSL handshake could not be performed.
>
> Host: Reason: error:14094416:SSL
> routines:ssl3_read_bytes:sslv3 alert certificate unknown:state
> 23:Application response 500 handshakefailed
>
>
> generated 2017-04-24 15:28:13 by we
On 24/04/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote:
> I use a 3rd-party application that is trying to update itself (so
> it’s trying to “call home”). Naturally, I’m behind a corporate
> firewall and Web proxy. The app has been configured to use that
> proxy. It fails to connect. Packet capt
> I use a 3rd-party application that is trying to update itself (so it’s
trying to “call home”).
> Naturally, I’m behind a corporate firewall and Web proxy. The app has
been configured to use
> that proxy. It fails to connect. Packet capture reveals the following:
You're noti
> On Apr 24, 2017, at 5:18 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>
> I use a 3rd-party application that is trying to update itself (so it’s trying
> to “call home”). Naturally, I’m behind a corporate firewall and Web proxy.
> The app has been configured to use that proxy. It fails to co
I use a 3rd-party application that is trying to update itself (so it’s trying
to “call home”). Naturally, I’m behind a corporate firewall and Web proxy. The
app has been configured to use that proxy. It fails to connect. Packet capture
reveals the following:
Handshake failed
The SSL handshake
22 matches
Mail list logo
