The remote certificate is invalid according to the validation procedure

Question

Running the following code, I get an exception:

using (var client = new Pop3Client())
{
    client.Connect(provider.ServerWithoutPort, provider.Port, true);
}

The Exception I get:

The remote certificate is invalid according to the validation procedure.


   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
   at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost)
   at OpenPop.Pop3.Pop3Client.Connect(String hostname, Int32 port, Boolean useSsl, Int32 receiveTimeout, Int32 sendTimeout, RemoteCertificateValidationCallback certificateValidator)
   at OpenPop.Pop3.Pop3Client.Connect(String hostname, Int32 port, Boolean useSsl)
   at Ugi.Server.Sources.Logic.SourcesService.IsValidPop3Connection(String email, String emailPassword) in C:\Users\elad\Documents\Visual Studio 2010\Projects\SVN\UGI\Ugi\Server\Sources\Logic\SourcesService.cs:line 246

Solution 1

This usually occurs because either of the following are true:

• The certificate is self-signed and not added as a trusted certificate.
• The certificate is expired.
• The certificate is signed by a root certificate that's not installed on your machine.
• The certificate is signed using the fully qualified domain address of the server. Meaning: cannot use "xyzServerName" but instead must use "xyzServerName.ad.state.fl.us" because that's basically the server name as far as the SSL cert is concerned.
• A revocation list is probed, but cannot be found/used.
• The certificate is signed via intermediate CA certificate and server does not serve that intermediate certificate along with host certificate.

Try getting some information about the certificate of the server and see if you need to install any specific certs on your client to get it to work.

Solution 2

Even shorter version of the solution from Dominic Zukiewicz:

ServicePointManager.ServerCertificateValidationCallback += (o, c, ch, er) => true;

But this means that you will trust all certificates. For a service that isn't just run locally, something a bit smarter will be needed. In the first instance you could use this code to just test whether it solves your problem.

Solution 3

.NET is seeing an invalid SSL certificate on the other end of the connection. There is a workaround for it, but obviously not recommended for production code:

// Put this somewhere that is only once - like an initialization method
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateCertificate);
...

static bool ValidateCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors)
{
   return true;
}

Solution 4

I had the same problem while I was testing a project and it turned that running Fiddler was the cause for this error..!!

If you are using Fiddler to intercept the http request, shut it down ...

This is one of the many causes for such error.

To fix Fiddler you may need to Reset Fiddler Https Certificates.

Solution 5

You must check the certificate hash code.

ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain,
    errors) =>
        {
            var hashString = certificate.GetCertHashString();
            if (hashString != null)
            {
                var certHashString = hashString.ToLower();
                return certHashString == "dec2b525ddeemma8ccfaa8df174455d6e38248c5";
            }
            return false;
        };

View more solutions

Comments

[Gilles]

@BoPersson except that other question has an horrible accepted upvoted answer.

[B.K.]

I get prompted twice. Once upon connection and once upon file upload. Is that normal? I inserted the code per your instructions. One at initialization and one in my FTP class.

[Jerico Sandhorn]

You should never recommend this approach toward solving trust without explaining the risks.

[Squazz]

Keep coming back to this. Root certificate, every time. Thanks a bunch! :D

[Squazz]

See this answer for why you should only do this in rare cases: stackoverflow.com/a/6613434/1955317

[Squazz]

Damn... Back here again, and this time it's none of the above points :/

[XYZ]

@Squazz: did you resolve it? any new points to add?

[Squazz]

Unfortunately not @XYZ, we ended up doing something else :/

[WooHoo]

The link to Resetting the Fiddler Https Certificates worked for me, thanks.

[BozoJoe]

seems rather obvious to NOT use in production. But to get moving in development this is a god-send

[BozoJoe]

hooray ServicePointManager to the rescue again in development

[vbezhenar]

* The certificate is signed via intermediate CA certificate and server does not serve that intermediate certificate along with host certificate.

[Anders Abel]

@vbezhenar Thanks, I'll edit that point into the answer.

[Andrew T Finnell]

I'm running into this issue now, and I've put the Self-Signed CA into both the Admin Trusted Root store, and the User Trusted Root Store. It still rejects the certificate. I am connecting to the server using 'my-server' and the Certificate is signed for 'my-server'. It's unfortunate the reason it rejects it isn't more clear.

[Reyan Chougle]

Thanks @Squazz for sharing the link

[user224567893]

the reason I was getting this error had nothing to do with the cert (the cert was fine), but the endpoint that I was using in the outgoing request was incorrect

[Eugene Ryabtsev]

Having this issue right now with RemoteCertificateNameMismatch in sslPolicyErrors. It seems the subject name does not match and alt names are not fully checked (the name is there in alts as the subject IP address and it works in the browser). Works with DNS name though. This seems to be fixed in latest .NET and/or Windows.

[Abuzar Ansari]

Thank you so much @brimble2010 , it has taken 2 days to work on development environment.

[Dan Chase]

@BozoJoe said another way, "only do this if this is a school project", otherwise I can't imagine it's place.

[Morgeth888]

adding this here to help folks and answers are locked but if your using HttpClient and dotnet core you will need to do something like this instead, again not a safe solution but handy for local dev concepts; HttpClientHandler handler = new HttpClientHandler(); handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidat‌​or; _client = new HttpClient(handler);

[tgolisch]

This approach also allows you other options for inspecting the X509Certificate before deciding to (always) return true

[Jimbo]

You, my friend, are a champion :) quick and simple fix to a potentially overwhelming issue!