Thursday, 9 March 2017

Could not establish trust relationship for the SSL/TLS secure channel with authority

This was a surprising and annoying error we experienced on Microsoft Azure when our web app was calling a WCF web service but it was only happening randomly.

Fortunately, I knew certain things worked which made it easier to narrow-down the problem.

I knew the web service worked, I knew I could connect to it with a valid SSL certificate chain, the only variable was that I was using Azure Traffic Manager to balance load between Japan and Ireland. Normally, the web apps in their respective areas would get sent to their local web service but in the unlikely event an entire web service dies, Traffic Manager could send the request to the other data centre.

Every now and then, I would see the following error:


The underlying issue is that when you make an SSL connection to a load balancer, the load balancer terminates the SSL (usually) so that if your request gets sent to a different web server, your connection stays up OK.

HOWEVER, if your request gets sent to another load-balancer, which would happen if Traffic Manager decided your previous one was unavailable, then the SSL connection cannot be resumed on the new load-balancer and you get the error above which, as often, contains a misleading message.

You wouldn't notice this effect in a browser since browser will automatically retry the connection if it drops, in which case they would reestablish the connection to the new load balancer and carry on. The call from the web app to the web service uses SvcUtil.exe to create a proxy class and this doesn't have any built-in functionality for reestablishing dropped SSL connections, it will instead throw the Exception and fail.

There is a project that provides some error handling for web service clients provided here, which I haven't tried but which looks like it might get around the problem.

I have worked around the problem by disabling Traffic Manager for the app to web service call so it is always local, which opens up a small risk if one web service died, but it should be OK for now.

Friday, 3 March 2017

Azure Traffic Manager shows degraded status for App Services https

I was surprised to see that the endpoints that Azure Traffic Manager was monitoring were showing degraded.

I looked into it and Google said that the Traffic Manager would check for a 200 response (and it won't follow 3xx responses) from the site but from where was it calling?

I thought that the problem might be the http->https redirect I had on the site so I needed the Traffic Manager to call the https endpoint and not the http one but when you click on the endpoint and press Edit, it doesn't show the endpoint.

What you need to do INSTEAD is to click Configure on the Traffic Manager itself and set the endpoint location in there:


Note that I am using the favicon in the path. The reason for this is that if I hit the default endpoint (/) it might cause a redirect to another page. Favicon is a nice static known resource that should always return 200. You could, of course, point it to anything else.

Tuesday, 7 February 2017

nginx returns 200 for image but no image!

This was a weird one. I copied a site into a new directory on a web server, set up nginx for the new site and accessed it. The php files worked as expected but I noticed an image wasn't displayed properly.

When I looked in the network tab, the server had returned a 200 for the image but trying to view the image showed something that wasn't the image it was supposed to be.

Very confusing but very simple!

The images I had copied up were corrupted somehow (possibly a previous use of WinSCP in text mode?) so the browser couldn't displayed them properly although nginx found them and returned them.

I had the originals on the web server so re-copied those into the new directory and it was all good!

Monday, 30 January 2017

Azure App Services. http works but https doesn't

The statement in the title is not true but I thought it was. Why?

I deployed from Visual Studio, using web deploy, directly to an App Services web app. It was a WCF web service project and when I visited with http, it worked fine. I then uploaded a TLS cert, setup the custom domain, tried to visit and BANG.

Once I had enabled all my detailed errors and read the log, the only information was 0x80070005 - Access Denied.

No real clues what was going on and what "access" is deined.

Anyway, after 90 minutes of poking around by an MS support technician, it appears that there is a compatibility problem when using Client Certificates. I was using one and although I had not used Resource Manager to deploy the app, there is a resource manager and its default configuration is:

"clientCertEnabled": false,

Open up the site's resource group in Resource Explorer, navigate to the site itself and you'll see the json on the right-hand side. Press the Edit button, find this setting, edit it to be true and PUT it and it should all magically come to life!

I need to automate this, but it will be fine for now.

Wednesday, 25 January 2017

WSUS client download error 0x800b0109 "Some update files aren't signed correctly"

This is another error that says what the problem is but doesn't give you any clues.

In the case of setting up a WSUS server to serve Windows Updates over a LAN, the WSUS server creates an SSL certificate for the endpoints and chains this to a self-signed root cert that is installed on the sever only.

When a client connects, due to the absence of a chain of trust, downloading metadata fails and the brief error above appears.

What you need to do is find the SSL cert being used on the WSUS server in IIS (under bindings on the main site), then export this certificate without private key from mmc.exe, then distribute this to your client PCs.

I'm sure you can automate this with GP but I just emailed it out for people to use!

Simples.

Wednesday, 21 December 2016

UnableToResolvePhysicalConnection UnableToConnect

"No connection is available to service this operation: GET"
"It was not possible to connect to the redis server(s); to create a disconnected multiplexer, disable AbortOnConnectFail. ConnectTimeout"

Redis, running on Windows with the default settings.

The problem? ssl was set to true in the connection string but not setup on the server. I set ssl to false (it is only for development) and it all works fine. Why would this not return a useful error like "ssl not setup on server"?

We only found out when one of our Devs happened to spot the ssl setting and wondered if that was why it worked in production and not in dev!

Tuesday, 20 December 2016

MSTest and Unit Tests for .Net on Bamboo - setting the path to the dll

We are starting to use Atlassian Bamboo, a build server that integrates really well with Bitbucket for building git repos.

Anyway, we mostly use .Net and getting that to build was OK but now we have added Unit Tests as well. I added another stage, with another job and an MSTest task and typed in the name of the test dll but it wouldn't work (file not found). I then found out about bamboo server variables and tried adding this to the path to the dll but still didn't work.

Basically, each job has its own build directory so although the application and test dll had been built by the previous stage/job, the unit test job then starts from an empty build directory.

You can share artifacts across jobs using the artifacts tab but in this case, it seems to make more sense simply to put the unit test task into the same stage as the compile task so they share the directory.

Easy peasy.