The march of freely available TLS certificates for domain validation continues in the form of the Let’s Encrypt project and I’m very pleased that it does.

I’m very happy with the Certbot client on most systems where I need to deploy Let’s Encrypt, but on hosts facing the big wide world that are Windows-based, Certbot obviously is not an option!

Fortunately, I’ve had success with the ACMESharp library for PowerShell. What’s cool about the library is that it does break down the process into individual commands, meaning you can automate, script and report on your certificate status with a great deal of flexibility.

For simpler scenarios, though, the letsencrypt-win-simple client offers a nice friendly command line interface to the ACMESharp library and is a nice easy way to quickly retrieve and install a Let’s Encrypt certificate on a public-facing IIS instance. Automating the renewal process is easy too — just create a Task Scheduler task.

Yes, it’s a command line client, and there are Windows folks who may not be comfortable with that, but it walks you through every part of the process. No memorising of switches and flags are needed!

There really is no excuse — now is the perfect time to get everything on HTTPS!

In my recent trials and tribulations with ADFS 3.0, I came up against an issue where we were unable to host ADFS 3.0 with Nginx as one of the layers of reverse proxy (the closest layer to ADFS).

When a direct connection, or a cURL request, was made to the ADFS 3.0 endpoints from the machine running Nginx, all seemed well, but as soon as you actually tried to ferry requests through a proxy_pass statement, users were greeted with HTTP 502 or 503 errors.

The machine running ADFS was offering up no other web services — there was no IIS instance running, or anything like that. It had been configured correctly with a valid TLS certificate for the domain that was trusted by the certificate store on the Nginx machine.

It turns out that despite being the only HTTPS service offered on that machine through HTTP.sys, you need to explicitly configure which certificate to present by default. Apparently, requests that come via Nginx proxy_pass are missing something (the SNI negotiation?) that allows HTTP.sys to choose the correct certificate to present.

So, if and only if you are sure that ADFS is the only HTTPS service you are serving up on the inner machine, you can force the correct certificate to be presented by default, which resolves this issue and allows the Nginx reverse proxied requests to get through.

With that warning given, let’s jump in to what we need to do:

Retrieve the correct certificate hash and Application ID

netsh http show sslcert

You’ll need to note the appid and the certificate hash for your ADFS 3.0 service.

Set the certificate as the default for HTTP.sys

We’ll use netsh‘s interactive mode, as I wasn’t in the mood to figure out how to escape curly brackets on Windows’ command line!

You want the curly brackets literally around the appid, but not the certhash.

netsh
netsh> http
netsh http> add sslcert ipport=0.0.0.0:443 appid={appid-from-earlier} certhash=certhash-from-earlier

Verify the proxy_pass settings

Among other configuration parameters, we have the following in our Nginx server stanza for this service:

proxy_redirect off;
proxy_http_version 1.1;
proxy_request_buffering off;
proxy_set_header X-MS-Proxy the-nginx-machine;
proxy_set_header Host the-hostname-in-question

And, with that, we were successfully reverse proxying ADFS 3.0 with Nginx. 🙂

I read this BBC News story about mistakenly issued security certificates recently, which allowed the people with those certificates to impersonate any Google websites and intercept traffic to them. It struck me as quite significant that this particular story made it to &#8216mainstream’ tech reporting.

There is a more detailed, and perhaps more accurate, commentary on this attack on Freedom to Tinker. It perhaps may not have been ‘cyber criminals’ as the BBC reported it when I first viewed the story!

Anyway, given the attention to this issue, I thought it a good opportunity to review this kind of attack against SSL/TLS — the security system upon which we all now depend. More importantly, I wanted to show Certificate Patrol, an add-on for Firefox that would allow you to notice a suspicious change to an certificate and thwart this kind of attack.

The weaknesses inherent in having too many organisations that are able to issue security certificates for any domain are becoming more clear. While this kind of attack is extremely rare, at the moment, ‘at the moment’ is a very poor security response! Hopefully, more awareness of these limitations of the internet’s authentication infrastructure can help put pressure on browser vendors, website owners and CAs to make everyone more secure.