What is the equivalent of the Trusted Root Certification Authority on Linux

[valeriob]

where i can put my self signed certificate so that when i make a http request to an host that uses it with System.Net.HttpClient it does work correctly instead of the exception ?

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

I tried putting the .cer inside /usr/local/share/ca-certificates and then update-ca-certificates (Ubuntu 18.04), without luck.

Thanks Valerio

[jcmcken]

We're seeing a similar issue to this after installing a renewed certificate from a recently renewed CA on our package repository.

It had been working with both .NET 2 and 3 before the cert switchover. But now, both .NET 2 and 3 now fail, so it seems like there's some implementation detail with the new CA or new cert, but the dotnet command basically gives no useful information about what the problem is.

Using curl works, hitting via the browser works. This is a CA we also use in AWS, so it's a valid chain (otherwise AWS would complain if we tried to upload the certificates).

The only difference in the CA I see is some new certificate policy OIDs added and the signature is larger (maybe it went from 2048 to 4096 bytes). The new certificate looks basically the same too (except in obvious places, like the signature, serial #, etc.).

We also tried reducing the local CA chain to just the necessary components to perform verification (e.g. we removed all other CAs not in the direct line of verification), but this had no effect.

[jcmcken]

Also, as a side note, we run other package repository formats like Docker, yum, NPM, PyPI. All of these work fine with the new certificate and CA. So this is a more than a little baffling.

[jcmcken]

Another side note: The PFX file that gets generated in ~/.dotnet/corefx/cryptography/x509stores/my/ has a certificate with CN localhost. I'm not sure if this matters or not, but it seems like it might be relevant. After running strace on my dotnet add package command, I'm not really seeing where this certificate comes from, if it comes from my system at all. I'm executing these commands in Docker containers, so the environments are completely clean and shouldn't have changed compared to the old behavior.

[bartonjs]

@valeriob Are you still having issues?

Assuming that you mean

• A self-signed certificate was created on the server
• The server is using that self-signed certificate as a TLS server cert
• The calling client is an Ubuntu 18.04 machine, and
  • Copied the certificate, in a PEM format with a .crt extension to /usr/local/share/ca- certificates
  • Then ran update-ca-certificates

Then the cert would be trusted. The validation can then still fail for other reasons: The certificate can not be valid as a TLS Server cert (e.g. it's a codesign-only cert), or the hostname can not match. If you use the server cert validation callback then the chain object would have any errors (including NotValidForUsage if it's that the cert isn't valid as a TLS Server cert, or UntrustedRoot if the root trust failed), if it's the hostname then that would be reflected in the SslPolicyErrors value.

[wfurt]

did you get it working @valeriob and @jcmcken? This seems pretty old and @bartonjs provided instructions. Note that on Linux EKU also must be properly set for self-signed certs (https://github.com/dotnet/runtime/issues/2122)

[jcmcken]

@wfurt Our problem isn't related to that. This is our issue (I believe). .NET has much stricter X509 policy checking than browsers and other tools.

This issue is one we escalated through Microsoft for our specific issue.

[wfurt]

ok. So it is tracked separately with more details @jcmcken. And it is separate from question how to update trusted CA list on given Linux distro, right?

[jcmcken]

@wfurt I believe so. In our case, the system CA works for other tools, just not .NET. So our CA bundle seems correct.