3

I'm writing a little c# "worker-service" with .Net Core 3.1. I need to access an API on HP Printer's (professional plotters) where the SSL certificate is provided but not trusted by the OS. So i'm always getting the error

The SSL connection could not be established, see inner exception.

Where the inner exception is:

Authentication failed, see inner exception.

And the last inner exception is:

The token passed to the function is invalid.

The code i have looks like this so far:

try
{
    using (var httpClientHandler = new HttpClientHandler())
    {
        httpClientHandler.ServerCertificateCustomValidationCallback = (message, cert, chain, sslPolicyErrors) => true;
        using (var httpClient = new HttpClient(httpClientHandler))
        {
            var httpResponse = httpClient.GetAsync("http://" + protocolRelativeUrl).Result;
        }
    }
} catch (Exception e)
{
    logger.LogError(e.Message);
}

I've stumbled upon these posts already:

But without any luck.. I think the problem could be that the certificate seems to be valid, but is not trusted by my OS:

certificate-of-printer

The other thing is, when i debug my code - i never step into the callback ServerCertificateCustomValidationCallback..Of course it is not working then :-/ But how could i get this working to actually fetch the data again and bypass this certificate check?

UPDATE

The content of the certificate as base64 is this:

-----BEGIN CERTIFICATE-----
MIICTDCCAbWgAwIBAgIE4yPFYjANBgkqhkiG9w0BAQQFADBZMR4wHAYDVQQDDBVI
UCBEZXNpZ25qZXQgRDQ5RUUyNkIxDzANBgNVBAoMBkhQIENvLjEVMBMGA1UECwwM
OENEQ0Q0OUVFMjZCMQ8wDQYDVQQLDAZGMkw0NkEwHhcNMjEwNzE5MDAwMDAwWhcN
MjYwNzE5MDAwMDAwWjBZMR4wHAYDVQQDDBVIUCBEZXNpZ25qZXQgRDQ5RUUyNkIx
DzANBgNVBAoMBkhQIENvLjEVMBMGA1UECwwMOENEQ0Q0OUVFMjZCMQ8wDQYDVQQL
DAZGMkw0NkEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALGW0b2wl9PDiMx2
6iQ2+iqUmqbCCoJczEjf7asjmGunIZpcddMkffYUhxTyVp0Hiap3zhsvTu1yBxW0
0y1gojE6Cw5/UTAdJVQ9f7DfcCEfKEeGKX/v8k8L/vM8cXLbnAAt177erGMUHl4n
2Zsvu0vB3RuAkkDj99RkRPSBHcexAgMBAAGjITAfMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCl5cBAkpW2YK1uN7Xg5MEi
wHtusKsmmCM4I46timFwti4rcKQzJC/lqM7w1z0k4sB7VIgn73Q4uymAEgyqokC5
ID2Yqw5T/O4Tt/PSxn9mnEdV/NTNH2c19XRv1I+YWhiKRgcEOF7gHNiYQdoHSaM5
ZKOUR8nYhLZCg2y+BJuzaw==
-----END CERTIFICATE-----

jebbie
  • 1,418
  • 3
  • 17
  • 27
  • 1
    [This answer](https://stackoverflow.com/a/54523827/3181933) suggests that it can be beacuse _"Certificate on the chain is signed with an unsupported or disabled algorithm."_ - what is the algorithm on the certificate? Better yet, perhaps you could click "Copy to file" on the "Details" tab, export it to a base64 file, and include it in your question? – ProgrammingLlama Oct 22 '21 at 16:10
  • @Llama i've updated the question with the certificate as base 64 – jebbie Oct 22 '21 at 16:26
  • @Llama uhm, how can i correctly detect the algorithm which is used by this certificatae..? – jebbie Oct 23 '21 at 10:23
  • I'm honestly not sure if that's the issue. I tried reading your certificate directly with the `X509Certificate` class and that was OK by itself, though I'm not sure how the certificate is read in the context of a HTTP request. I was kind of hoping someone else would have an answer, armed with the certificate. – ProgrammingLlama Oct 23 '21 at 12:18

1 Answers1

1

I have found the answer i was looking for - it was written as a comment in one of the threads here: Allowing Untrusted SSL Certificates with HttpClient

This means - it is impossible to solve this issue with .net core 3.1 - and switching back to .net 2.x is not an option. Fixing the certificate is impossible too as it is a printer with a built-in webserver and HP decided to offer self-signed certificates with the algorithm MD5. And it would not be cool to tell our customers to install a custom made (valid) certificate first on their printer - our customers are not computer scientists..

Installing the certificate on the system or allowing the RSA/MD5 algorithm in the registry key HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003 Functions is not working too. The callback ServerCertificateCustomValidationCallback will never be executed with such a certificate!

Sooo, how did i solve it? With a different technology :-) Now i'm using the Nuget Package Python.Included and i'm making the HTTPS request trough python. Because python still allows to completely bypass any SSL certificates, YAY!

My final code looks now like this:

try
{
    PythonEngine.Initialize();
    dynamic sys = PythonEngine.ImportModule("sys");
    dynamic ssl = PythonEngine.ImportModule("ssl");
    try
    {
        ssl._create_default_https_context = ssl._create_unverified_context;
    }
    catch (Exception e)
    {
        SentrySdk.CaptureException(e);
    }
    dynamic urllibRequest = PythonEngine.ImportModule("urllib.request");
    var httpResponse = urllibRequest.urlopen("https://" + protocolRelativeUrl).read();
    return FetchHttp.SanitizeResult(httpResponse.ToString());
}
catch (Exception e)
{
    logger.LogError("Could not fetch url: " + protocolRelativeUrl);
    logger.LogError(e.Message);
    SentrySdk.CaptureException(e);
}

And it's working! <3

jebbie
  • 1,418
  • 3
  • 17
  • 27
  • 1
    The actual solution is to trust the certificate and *not* use a broken algorithm. `allowing the RSA/MD5 algorithm in the registry key` that's just broken – Panagiotis Kanavos Oct 26 '21 at 10:33
  • @PanagiotisKanavos and how should this be possible to "trust" it when it is MD5? – jebbie Oct 26 '21 at 10:34
  • Don't use MD5. There's absolutely no excuse for this. It's broken and little better than not using SSL at all - as in, it would take a few seconds to crack it. – Panagiotis Kanavos Oct 26 '21 at 10:35
  • To put it another way, if anything goes wrong in that network guess who's getting a call first ... – Panagiotis Kanavos Oct 26 '21 at 10:36
  • It's running in LAN without any access from outside... i have no other possibility to bypass these broken printer certificates as i cannot fix them – jebbie Oct 26 '21 at 10:37
  • 1
    And if that seems extreme, remember that hacked printers were used for DDOS attacks a few years *before* COVID. HP disabled the web services on its printers precisely for this reason – Panagiotis Kanavos Oct 26 '21 at 10:38
  • `without any access from outside.` the hacked printers weren't accessible from the outside either. They were infected then used to attack outside targets. All it takes in infecting a single machine, then using it to scan the network for vulnerable targets – Panagiotis Kanavos Oct 26 '21 at 10:39
  • just for clarification, it's not me using MD5... it's HP which pre-installs MD5 certificates on their biggest plotter-printers (which is really really bad i know) – jebbie Oct 26 '21 at 10:39
  • And as I said, HP itself disabled web services to these machines years ago. I also have an HP printer that could download small apps and printables until the widespread DDOS attacks forced HP to disable essentially everything. Except the firmware that wrecks your printer if you use non-HP inks. Priorities .... – Panagiotis Kanavos Oct 26 '21 at 10:42
  • 1
    I'll assume that HP no longer supports those machines. This is an ugly situation. In that case you shouldn't trust the MD5 certificates. One option would be to actually use a computer as a print server instead of connecting to them over the network. Using a firewall would also work, but that would require extra work. – Panagiotis Kanavos Oct 26 '21 at 10:44
  • interesting informations, but obviously HP did not disable it for their professional plotter printers (the really big ones, you don't have one of these at home)... there is plenty of HP software which relies on the webservice of these printers which all would stop working... this would be a no-go for all running print-shops out there (for whom we are developing software too) – jebbie Oct 26 '21 at 10:44
  • The really big ones are even bigger attack targets. `Iranian Centrifuges` comes to mind, but a few years back professional Miele fridges were found to have essentially unprotected Ethernet connections. `for whom we are developing software too` which makes you liable for any hacks, unless the customer explicitly accepts the risk of using MD5. After all, it's the customer that can contact HP to fix its certificates. You should strongly consider *not enabling* this fix by default – Panagiotis Kanavos Oct 26 '21 at 10:48
  • @PanagiotisKanavos after all - thanks a lot for sharing your concerns, i try to contact HP support to clarify the whole situation ;-) At least we can continue with development of our software for now – jebbie Oct 26 '21 at 10:55