# HG changeset patch
# User Sergey Kandaurov <pluknet@nginx.com>
# Date 1590783020 -10800
# Node ID 1b4ceab9cb1cd676b62fe99ec9beb87dd7b24887
# Parent  0077b80ef745aa9073bda4334af4e3a3f9d2e491
Tests: fixed ssl_certificate.t with LibreSSL client.

Net::SSLeay::connect() that manages TLS handshake could return unexpected
error when receiving server alert, as seen in server certificate tests if
it could not been selected.  Typically, it returns the expected error -1,
but with certain libssl implementations it can be 0, as explained below.

The error is propagated from libssl's SSL_connect(), which is usually -1.
In modern OpenSSL versions, it is the default error code used in the state
machine returned when something went wrong with parsing TLS message header.
In versions up to OpenSSL 1.0.2, with SSLv23_method() used by default, -1
is the only error code in the ssl_connect() method implementation which is
used as well if receiving alert while parsing ServerHello.  BoringSSL also
seems to return -1.  But it is not so with LibreSSL that returns zero.

Previously, tests failed with client built with LibreSSL with SSLv3 removed.
Here, the error is propagated directly from ssl_read_bytes() method, which
is always implemented as ssl3_read_bytes() in all TLS methods.  It could be
also seen with OpenSSL up to 1.0.2 with non-default methods explicitly set.

diff --git a/ssl_certificate.t b/ssl_certificate.t
--- a/ssl_certificate.t
+++ b/ssl_certificate.t
@@ -227,7 +227,7 @@ sub get_ssl_socket {
 	Net::SSLeay::set_tlsext_host_name($ssl, $host);
 	Net::SSLeay::set_session($ssl, $ses) if defined $ses;
 	Net::SSLeay::set_fd($ssl, fileno($s));
-	Net::SSLeay::connect($ssl) or die("ssl connect");
+	Net::SSLeay::connect($ssl);
 	return ($s, $ssl);
 }