[openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
Michael Wojcik
Michael.Wojcik at microfocus.com
Thu Nov 9 02:17:30 UTC 2017
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Graham Leggett
> Sent: Wednesday, November 08, 2017 20:11
> To: openssl-users at openssl.org
> Subject: [openssl-users] Ubuntu Xenial + Postgresql v9.5 == SSL
> routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
>
> - What is the significance of "no peer certificate available”?
You can get this message from s_client even if the handshake failed for other reasons. I've seen it when there are no common cipher suites, for example. One case I recently observed: A stock OpenSSL 1.0.2j s_client talking to an older IIS. IIS negotiated TLSv1.2 but didn't actually support any of the TLSv1.2 suites. s_client reported the negotiated suite was 0 (i.e. none), but it also gave me the "no peer certificate" diagnostic. (In this case, forcing TLSv1.1 got the connection working, and since this was for an internal demo I didn't bother beating IIS into submission.)
> New, (NONE), Cipher is (NONE)
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : 0000
Yeah. TLSv1.2, no cipher. My guess is the server is allowing the 1.2 protocol level but not supporting any of the 1.2 suites.
> ssldump confirms that it is the client side - that’s openssl - that’s rejecting the
> handshake and returning unknown ca:
>
> New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432)
> 42 1 0.0038 (0.0038) C>SV3.1(300) Handshake
> ClientHello
> Version 3.3
> random[32]=
> 80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1
> 33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24
> cipher suites
> Unknown value 0xc030
> Unknown value 0xc02c
> Unknown value 0xc028
> Unknown value 0xc024
> Unknown value 0xc014
> Unknown value 0xc00a
> Unknown value 0xa5
> Unknown value 0xa3
> Unknown value 0xa1
> Unknown value 0x9f
> Unknown value 0x6b
> Unknown value 0x6a
> Unknown value 0x69
> Unknown value 0x68
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> TLS_DH_RSA_WITH_AES_256_CBC_SHA
> TLS_DH_DSS_WITH_AES_256_CBC_SHA
> Unknown value 0x88
> Unknown value 0x87
> Unknown value 0x86
> Unknown value 0x85
> Unknown value 0xc032
> Unknown value 0xc02e
> Unknown value 0xc02a
> Unknown value 0xc026
> Unknown value 0xc00f
> Unknown value 0xc005
> Unknown value 0x9d
> Unknown value 0x3d
> TLS_RSA_WITH_AES_256_CBC_SHA
> Unknown value 0x84
> Unknown value 0xc02f
> Unknown value 0xc02b
> Unknown value 0xc027
> Unknown value 0xc023
> Unknown value 0xc013
> Unknown value 0xc009
> Unknown value 0xa4
> Unknown value 0xa2
> Unknown value 0xa0
> Unknown value 0x9e
> TLS_DHE_DSS_WITH_NULL_SHA
> Unknown value 0x40
> Unknown value 0x3f
> Unknown value 0x3e
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> TLS_DH_RSA_WITH_AES_128_CBC_SHA
> TLS_DH_DSS_WITH_AES_128_CBC_SHA
> Unknown value 0x9a
> Unknown value 0x99
> Unknown value 0x98
> Unknown value 0x97
> Unknown value 0x45
> Unknown value 0x44
> Unknown value 0x43
> Unknown value 0x42
> Unknown value 0xc031
> Unknown value 0xc02d
> Unknown value 0xc029
> Unknown value 0xc025
> Unknown value 0xc00e
> Unknown value 0xc004
> Unknown value 0x9c
> Unknown value 0x3c
> TLS_RSA_WITH_AES_128_CBC_SHA
> Unknown value 0x96
> Unknown value 0x41
> Unknown value 0xc011
> Unknown value 0xc007
> Unknown value 0xc00c
> Unknown value 0xc002
> TLS_RSA_WITH_RC4_128_SHA
> TLS_RSA_WITH_RC4_128_MD5
> Unknown value 0xc012
> Unknown value 0xc008
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
> Unknown value 0xc00d
> Unknown value 0xc003
> TLS_RSA_WITH_3DES_EDE_CBC_SHA
> Unknown value 0xff
> compression methods
> NULL
> 42 2 0.0056 (0.0017) S>CV3.3(62) Handshake
> ServerHello
> Version 3.3
> random[32]=
> f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac
> 9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13
> session_id[0]=
>
> cipherSuite Unknown value 0xc030
Hmm. This claims they agreed on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Maybe no ECC curves in common for ECDHE Kx?
> compressionMethod NULL
> 42 3 0.0056 (0.0000) S>CV3.3(3345) Handshake
> Certificate
> certificate[1329]=[snip]
> certificate[1010]=[snip]
> certificate[990]=[snip]
> 42 4 0.0056 (0.0000) S>CV3.3(333) Handshake
> ServerKeyExchange
> 42 5 0.0056 (0.0000) S>CV3.3(179) Handshake
> CertificateRequest
> certificate_types rsa_sign
> certificate_types dss_sign
> certificate_types unknown value
> Not enough data. Found 163 bytes (expecting 32767)
> ServerHelloDone
Not seeing any curve agreement there. There should be a ServerKeyExchange before the ServerHelloDone, if memory serves. (Someone may correct me on this - it's been some time since I looked at the details of ECDHE key exchange.)
> 42 6 0.0061 (0.0004) C>SV3.3(2) Alert
> level fatal
> value unknown_ca
This looks to me like the wrong Alert value, but again maybe someone can correct me on that.
Anyway, my suggestion is try setting a cipher list that doesn't include the ECC suites, to confirm that's the problem.
--
Michael Wojcik
Distinguished Engineer, Micro Focus
More information about the openssl-users
mailing list