> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Graham Leggett > Sent: Wednesday, November 08, 2017 20:11 > To: openssl-users@xxxxxxxxxxx > Subject: 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
