3

I know there are several threads about this, but I think my case might be different.

Our application needs to send requests to 2 HTTPS URL's: one of them is the ReCaptcha service, and another is some government service from Brazil (if you are from Brazil, probably you know what SEFAZ and NF-e means :D)

Sometimes, both just stops working. The exception, as the title says, is "Could not establish trust relationship for the SSL/TLS secure channel". When one of them starts throwing the exception, the other starts throwing it too, and vice versa: while one of them works, the other works too.

Everything was running just fine until some days ago when this exception started throwing randomly. This exception throws in our production server and also in our internal development server.

So, there are 2 services (ReCaptcha and this governement service) that just stops working apparently at the same time in both servers, apparently randomly. They stop working and then start working again.

The CA root is different in both cases. One uses GeoTrust Global CA and the other uses ICP-Brasil.

Based on this thread, we thought that maybe the clock is wrong, but it apparently isn't. We check it constantly.

I know about this solution:

 ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

But it doesn't look very safe for me. Is there a problem using those solutions?

We could also use this:

ServicePointManager.ServerCertificateValidationCallback = 
    ((sender, cert, chain, errors) =>  cert.Subject.Contains("ServerName"));

But we are really curious about why this exception throws apparently randomly. We might use it if we don't solve it in a "proper" fashion.

So, we ran out of ideas. Our service runs on Windows Server 2008R2 and IIS 7.5. What else should I look for?

Community
  • 1
  • 1
Ricardo Pieper
  • 2,613
  • 3
  • 26
  • 40
  • 1
    Sounds more like a temporary networking issue. The exception message about ssl may be a red herring. Have you checked connectivity between your endpoints while this is happening? – Kevin Jul 10 '15 at 14:05
  • We didn't checked it... well, it might be. I'll try to do it. Thanks! – Ricardo Pieper Jul 10 '15 at 14:19

1 Answers1

3

ServicePointManager.ServerCertificateValidationCallback = ((sender, certificate, chain, sslPolicyErrors) => true);

But it doesn't look very safe for me. Is there a problem using those solutions?

Uhm, yes! With this, you're allowing every server with any certificate to be the server you think you're speaking with.

Same goes for this:

ServicePointManager.ServerCertificateValidationCallback = 
((sender, cert, chain, errors) =>  cert.Subject.Contains("ServerName"));

Only validating the Subject won't be enough here. You should at least apply more criteria here, e.g. GetSerialNumberString(), GetPublicKeyString() and GetCertHashString() to verify the correctness of the certificate. But IMHO: don't do this in live environment - never ever! - only for development and testing purposes.

Regarding the main error - a part of this answer you already linked might be the cause of the issue: When both certificates stop working at the same time, it's most likely to be an issue with the certificate chain. One part in the chain, that both certificates use might be unavailable, due to this the chain of trust is broken, and the secure channel cannot be established.

As far as I know, you should be able to override the ServerCertificateValidationCallback, log the certificate chain, and still return the basic validation afterwards. This would get you closer to the errors source.

Community
  • 1
  • 1
Stefan Over
  • 5,851
  • 2
  • 35
  • 61
  • 2
    Thanks! We logged the erros, and apparently our firewall sometimes just put it's certificate on the CA root, instead of the correct one. – Ricardo Pieper Jul 10 '15 at 15:27