Let’s break down what’s likely causing your SSL handshake failures across Linux, Windows C#, and your Apache reverse proxy, and walk through actionable fixes to get things working.

1. Diagnose the Core SSL/TLS Version & Cipher Suite Mismatch #

That SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure error from openssl s_client tells us the server is rejecting your client’s handshake attempt—most often because of a mismatch in supported SSL/TLS versions or cipher suites.

First, narrow down which protocols the server actually supports:

# Test with TLS 1.2 (most widely supported)
openssl s_client -connect your-server-domain:port -tls1_2
# Test with TLS 1.3 if you suspect the server supports it
openssl s_client -connect your-server-domain:port -tls1_3

If one of these works, your default client configuration (like openssl or curl) is probably using a protocol the server blocks (e.g., outdated SSLv3 or TLS 1.0).

Next, check the server’s supported cipher suites to ensure your client/proxy is using a compatible one:

# List server's cipher suites via openssl
openssl s_client -connect your-server-domain:port -cipher 'ALL'
# Or use nmap for a cleaner breakdown (if installed)
nmap --script ssl-enum-ciphers -p your-port your-server-domain

Compare these results to the cipher suites your curl, C# app, or Apache proxy is using—if there’s no overlap, that’s a clear culprit.

2. Fix Client Certificate Authentication Gaps #

Since both your Windows C# app and Apache proxy are failing at client auth, let’s validate the certificate setup:

For Linux/Apache Reverse Proxy #

Double-check your Apache SSL proxy config to ensure it’s correctly using the client certificate and trusting the server’s CA:

SSLProxyEngine On
# Enforce client certificate validation for the proxy
SSLProxyVerify require
SSLProxyVerifyDepth 3 # Match the depth of your certificate chain
# Path to the CA cert that issued the server's certificate
SSLProxyCACertificateFile /path/to/trusted-ca.pem
# Your client certificate (include the full chain: client cert + intermediate CAs)
SSLProxyCertificateFile /path/to/client-fullchain.pem
# Your client certificate's private key
SSLProxyCertificateKeyFile /path/to/client-key.pem
# Restrict proxy to supported protocols
SSLProxyProtocol TLSv1.2 TLSv1.3
# Use cipher suites the server supports
SSLProxyCipherSuite HIGH:!aNULL:!MD5:!RC4

Make sure you’ve combined your client certificate with any intermediate CA certs into a single client-fullchain.pem file—missing intermediates is a common auth failure cause.

For Windows C# HttpWebRequest #

Ensure your code is loading the client certificate correctly (including its private key) and using a supported TLS version:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://your-server-domain");
// Load PFX certificate (include password if protected)
X509Certificate2 clientCert = new X509Certificate2("client-cert.pfx", "your-cert-password");
request.ClientCertificates.Add(clientCert);
// Enable modern TLS versions (avoid outdated protocols)
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
// Temporary: Bypass server cert validation for testing (remove in production!)
request.ServerCertificateValidationCallback = (sender, cert, chain, errors) => true;

// Send request and handle response
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // Process response here
}

If the cert is stored in the Windows Certificate Store, use X509Store to load it instead of a file—this ensures the private key is accessible.

3. Deep-Dive with ssldump Traffic Analysis #

You already used tcpdump and ssldump—now focus on these key handshake stages to pinpoint the failure:

1. ClientHello: Check which protocol version, cipher suites, and extensions (like SNI) your client/proxy is sending. If the server rejects this immediately, it’s a protocol/cipher mismatch.
2. CertificateRequest: If the server sends this, it expects a client cert. Verify your client actually responds with the correct cert.
3. Alert(Handshake Failure): Look at when this is sent—if it’s after the client sends its cert, the server likely doesn’t trust the cert’s CA, or the cert is invalid (expired, wrong hostname, etc.).

Use this ssldump command to parse your pcap file with clear text output:

ssldump -r your-tcpdump-file.pcap -A -n

4. Validate Apache Proxy Logs #

Check your ssl_engine.log for specific error messages—these will tell you exactly why the proxy’s auth is failing:

• verify error:num=20:unable to get local issuer certificate: Missing intermediate CA cert in your proxy’s cert chain.
• verify error:num=27:certificate not trusted: The server doesn’t trust your client cert’s issuing CA.
• verify error:num=18:self signed certificate: Your client cert is self-signed and the server isn’t configured to trust it.

内容的提问来源于stack exchange，提问作者Fabien Sintès