I need to send https requests from .net console app running on Windows Server 2008 (nope, can’t update 🙁 ). Requests made by the app failed with the error:
Autentication failed vecause the remote party sent a TLS alert: HandshakeFailure
So I did some research and succeeded with calling curl from the app. I’d like to avoid using curl if possible, so I decided to try downloading Firefox CA certificate store and adding all it’s certificates to http client:
var caCerts = LoadCACertificates(pemFilePath);
using var httpClientHandler = new HttpClientHandler();
httpClientHandler.ClientCertificates.AddRange(caCerts);
using var httpClient = new HttpClient(httpClientHandler);
...
private static X509Certificate2Collection LoadCACertificates(string pemFilePath)
{
var certificates = new X509Certificate2Collection();
try
{
string pemContent = File.ReadAllText(pemFilePath);
// Extract each certificate in the PEM file
var matches = Regex.Matches(pemContent, "-----BEGIN CERTIFICATE-----(.*?)-----END CERTIFICATE-----", RegexOptions.Singleline);
foreach (Match match in matches)
{
string base64Cert = match.Groups[1].Value.Replace("r", "").Replace("n", "");
byte[] certBytes = Convert.FromBase64String(base64Cert);
var certificate = new X509Certificate2(certBytes);
certificates.Add(certificate);
}
}
catch (Exception ex)
{
Console.WriteLine($"Error loading CA certificates: {ex.Message}");
throw;
}
return certificates;
}
...
But without any success, I’m still getting the same error.
Please, has anyone any ideas, why the code doesn’t work?
6
-
While one possible cause of handshake_failure is not using a client cert AND KEY when the server demands client auth, ONLY a certificate WITH a private key can be a client cert;
you do not and never will have the private key for any CA trusted by Mozilla (or anybody else sensible). Did you specify a client cert AND KEY to curl?
If not and it worked without, then the server doesn’t require client auth; curl never defaults client cert, only a truststore of CA certs to verify the server cert — and that varies depending on how it is built. -
Another possibility is protocol version. Assuming you don’t mean R2, S2008 supports TLS versions above 1.0
only in SP2 with a patch AND registry changes.
SSL3 was totally broken in 2014 and has long been prohibited by everybody. TLS 1.0 is now considered obsolete and marginal, though not definitely broken,
and many servers won’t accept it; almost as many won’t accept 1.1 either. Among other things if a website wants to accept payment cards
the industry standard (PCI DSS) effectively prohibits everything below 1.2, and so do lots of governments, regulators, and other authorities, including IETF.You may be able to test this with curl, depending on which library it is built to use and possibly which version. (Use
--tls-max
and--tls-min
; the--tlsv{number}
options only set a minimum not an exact version.)
If you can’t test on the machine with the problem, use a different curl build, oropenssl s_client -tls{1,1_1,1_2,1_3}
(which is always exact), from another machine to the same server. -
Yet another possibility is Server Name Indication aka SNI.
Although defined earlier, in 2008 SNI was rarely used, and I’m pretty sure Vista didn’t support it,
so there’s at least a chance S2008 doesn’t. My search results are mostly about SNI support in IIS,
which was a big issue for a while, but client-side you don’t care about that, only about Schannel.
SNI became common during the 2010s, and today most public servers require it,
and often give handshake_failure if it is not provided. Any nonancient curl sends SNI.This can be tested with
openssl s_client
by specifying or omitting-noservername
(except OpenSSL below 1.1.1, which you aren’t likely to find today, but if you do I will update). -
A final but I think unlikely possibility is ciphersuites. For a while this was a problem on XP/S2003, which didn’t implement AES,
the only cipher from that period still accepted by many authorities and servers.
Vista, and I assume S2008, did implement AES, but conceivably your system has it disabled for some reason.
curl honors Windows cipher settings when built to use Schannel, but not when built for other libraries like OpenSSL. (You can see how it was built withcurl -V
uppercase-vee.)
6