TLS Issue when attempting to connect to SNow

[Ngauthier]

Hello all,

I am currently developing a console application in C# in order to perform small tasks inside of a Service-Now Instance. While originally, this was working well, it seems that now the service-now instance can not longer be accessed by my server or any server on that domain. This is due to the fact that when these devices attempt to perform the TLS handshake, after the Client Hello from our system, the Service-Now instance sends a TCP reset and the connection closes. I have tested this with other instances we own and the issue does not present. All Servers on the domain I am testing from are affected, and there are multiple networks to this domain. The device I am developing the console app on is a MS Server 2019. If I attempt to navigate to the website I get the unsecure/outdated TLS method IE error message. I tried to rend a request with Postman as well without success. I have exported the code and ran it without any issue outside that domain.

My question is, has anyone had this issue before? We are getting the TCP reset from the instance practically immediately. Any more suggested tips for me to troubleshoot? My network guys say they see traffic pass through without issue.

[Ngauthier]

No My console App doesn't do anything like that. I've even included a line specificly to force it to use only tls 1.2 to make sure that we were sending out proper handshake attempt. I have a wireshark on the host where my app is running where I can see a handshake attempt by my server and a tcp reset sent back by the service now instance.

Plus, if that were the case, wouldn't it be broken with all my service-now instances? At the same time, wouldn't postman word if that was the issue? I can see the exact same handshake behaviour when I just attempt to navigate to the site via browser. Any browser. With all that, I am almost certain the issue wouldn't be with my app but rather the network path between my forest's network and the service-now instance

[-O-]

Where did I ever write about what your application does or does not do?

Though the wording

replaces certificates on the console application

could in a weird twisted way be interpreted as me implying that the console application is doing something, the subject in that sentence is clearly not the console application.

I was talking about a TLS traffic interceptor. The way this works/is set up is so that it intercepts your TSL traffic like a web proxy. But in order fir this to work "transparently" what happens is that this traffic interceptor, in order to be able to do just that, it needs to replace the original certificate between it and your console app, and everything else, like browsers. And you have absolutely no control whatsoever as to what happens on the other end, that is between the TLS traffic interceptor and the actual web server. But it is easy to tell if such a thing is uses: you just need to consult the TLS certificate while trying to connect to SN in a browser. Is the certificate issues by Entrust, Inc?

Such a setup would explain why the failure happens both to your app and browsers. But it should happen to Postman too. Though there might be exceptions/rules as to when to interfere with TLS traffic and when not.

[Ngauthier]

Sorry about that. I did misunderstand exactly as you said. With the explanation provided what you are saying makes a lot more sense to me. I'll look into it and see if that's what's happening.

Two things I would like to clarify however.

1. Would this not cause an issue with all of my service-now instances since they all expect tls 1.2?

2. Where would that interceptor be located? As I am not a network admin I wouldn't have access to anything past the server. 

[-O-]

No problem.

As for the issues raised

1. It depends how the interceptor is configured; maybe some instances are excepted.

2. It would be a gateway or a proxy.

Though do note this is just an idea, might not be the case at all. The idea is to look at the certificate and you will be able to tell. If this is what is indeed happening, the certificate will be issued by your company, not Entrust, Inc.

Also, if this is the case, you will be able to sort it with the Network team anyway. So I would involve them right off the bat.

[Ngauthier]

Apologies for the long wait time on a reply.

After checking what you suggested, everything seemed to be normal. As in the certificate was from entrust and nkt my company. We managed to open a case with service now and a few hours later the connectivity restored. We are still unsure what caused it, and service now is not aware of what restored it.