The remote certificate is invalid according to the validation procedure #31514
Comments
|
I'm not familiar with MailKit, but after looking at their docs, it looks like they use the same static void Main(string[] args) {
MailKit.Net.Smtp.SmtpClient client = default; //setup client
client.ServerCertificateValidationCallback = (sender, cert, chain, errors) => {
// Log errors
// Log chain
// Log cert
return errors == SslPolicyErrors.None;
};
// Do thing with client.
}You could also attempt to connect to the mail server using openssl directly and see what it produces, something like: |
|
So I tried with openssl and that looked to work OK. I didn't really know what I was doing afterwards but I could start the EHLO process with no issues. I logged the results of the ServerCertificateValidationCallback, which shows RemoteCertificateChainErrors, the chain is shown below and it looks complete i.e. normal cert, intermediate and root but I don't know if there is an easy way to see this chain more like a browser shows is? I also returned "true" to ignore the errors and the message is sent without a problem. |
|
OK, so now I have some more information. I logged the chain element status and I saw this for my top level certificate:
This should give me more to dig into. |
|
If you are getting |
|
Hi @vcsjones that's the error I posted above. So apparently Lets Encrypt do not include a CRL for the server cert but use OCSP stapling instead so perhaps a better question is: Should the SSL connection be failing due to a CRL missing in the cert and not just fallback to OCSP? Of course I can leave the server check bypassed or try and ignore that specific error but that sounds a bit smelly to me - I am hoping there is a proper way to get around this? |
|
Can you try using .NET Core 3.0? There were a lot of fixes to TLS/SSL handling and perhaps one of those fixes might solve your problem. |
|
Ping @lukos? 2.2 will be out of support this month. |
|
In .NET Core 2.2 we didn't have support for OCSP on Linux. We added OCSP on Linux in .NET Core 3.0, so Let's Encrypt chains should cleanly build with revocation now. If you're seeing otherwise, let us know. |
|
I'm still gettting following errors targeting netcoreapp3.1 :
Minimal code example for repro with MailKit: when checking against openssl everything is fine with the certs help(?) |
maryamariyan
added
the
untriaged
|
Landed here after finding that this dotnet/aspnetcore issue and its resolutions (not its Stack Overflow thread on Adding some info here, as it might help with an easy repro. What I did was:
Because the instructions in Stack Overflow did not (yet) work for me somehow (even after
Then:
To my limited understanding it seems that my API is calling another "server" and is not trusting that server's SSL certificate. So I presume this is the same problem as OP has, only in their case it is "MailKit" that is running a cert that's not okay for the calling client (similar to my 'client' calling into IDS4)? I'm adding this information because:
I truly hope all this information in my post helps and is not completely off topic. If it is off-topic, then please ignore! What I did (to no avail) to try and fix the certificate (might be a valid workaround for OP even though it didn't work for me?):
Then |
|
I don't think the |
|
Thx for the response @wfurt! I appreciate the offer to look at my specific situation, but I don't want to dilute this GitHub issue with super-specific debugging of what is likely my own specific problem. Your tips were super helpful already though, grabbing the contents of the |
I finally figured out why this is not working on Linux. The netcore framework does not read from the OS's ca-certificates folder, but from
Therefore the app did not trust ANY certificates. So downoaded Google's sample PEM file from this page, converted it into a P7B file to make sure the entire certificate chain remains intact
and added the entire chain during app startup |
|
The |
|
Same issue here with a wildcard Certificate issued by letsencrypt (*.stg.foo.com) : Setup:
CURL works:
The certificate seems to be valid. I can access the URL with my browser, curl or openssl s_client HttpClient fails with: The remote certificate is invalid according to the validation procedure |
|
@Amberg If you have a stable repro, can you register a custom verification callback to report a) the SslPolicyErrors value An alternate, more expressive, (b) would be foreach (X509ChainElement element in chain.ChainElements)
{
Console.WriteLine($"{element.Certificate.Subject}: {element.ChainElementStatus.Aggregate(X509ChainStatusFlags.NoError, (f, s) => f | s.Status)}");
} |
|
BTW, when I checked against |
|
The correct url is The custom verification callback reports: openssl s_client foo.stg.cluyo.ch:443 |
|
Weird. On 3.1 we use OpenSSL's X509_check_host function. I see it as verifying from Ubuntu 18.04. To fully match what's going on from .NET, the equivalent check would be
At the bottom it should still say "Verify return code: 0 (ok)", which is what I get (though, honestly, I'd prefer it said "62 (Hostname mismatch)", since that'd show it was the library). There is a /slight/ difference, in that we specify X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, but that shouldn't apply. The only thing weird I see is that your CN has an asterisk in it. Often the CN will use a single full hostname but the Subject Alternative Names extension will contain the CN hostname as well as a wildcard. |
|
I have found the issue: I had a subdomain name with an underscore (which is not a valid host name) "foo_dev.stg.cluyo.ch" And I added the host name without wildcard stg.cluyo.ch to the certificate Some Browsers and "curl" seems to be less strict in this case |
|
The restriction about '_' comes from OpenSSL AFAIK. I'm wondering if there are some extra flags we can use to suppress it. |
My conclusion when investigating this in #35880 is that, no, this is not configurable. |
|
Coming from Ubuntu 20.04 and .NET 3.1 and I also get this error. Sometimes I fail to understand how a big company like Microsoft can't deliver a simple functionality like |
|
.NET Core is open source @Nefcanto. Feel free to contribute. |
|
This issue was ultimately that OpenSSL's hostname validation routine doesn't allow underscores. While underscores are permitted in DNS entries, they're not legal for hostnames (https://datatracker.ietf.org/doc/html/rfc1034#section-3.5), which is why OpenSSL doesn't consider it valid. The CA/Browser forum doubled down on that when they issued a rule that public CAs can't issue certs that contain underscores in SAN dNSName entries (and had to revoke any there were already so issued): https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/. |
ghost
locked as resolved and limited conversation to collaborators
Running a dotnet core 2.2 web api on Ubuntu 18.04 Docker image (mcr.microsoft.com/dotnet/core/aspnet:2.2-bionic). I am using MailKit (https://github.com/jstedfast/MailKit) to send an email and it works fine when I run locally on Windows 10 but fails on Linux:
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedureSince it works on Windows OK, it seems that there is perhaps an OpenSSL issue, maybe due to 1.0 vs 1.1? MailKit calls into SslStream.AuthenticateAsClient, which is the start of the stack that fails. Since this is an email relay, I need some other way of debugging that rather than just that https works generally (which it does with curl).
I have tried the following to no avail:
Can someone please give me some more debugging tips? Thanks.
The text was updated successfully, but these errors were encountered: