More information about the Underscore mailing list

[_] https://www

Pete Williamson pete at
Tue Apr 23 08:48:20 BST 2019

I've not used Azure, but it took quite a bit of effort to get Let's Encrypt to work with a Rackspace Load Balancer. Anything beyond a simple "this site is on this server" setup and Let's Encrypt gets awkward.

There's a "manual" mode with certbot that lets you run a script before and after authentication and then a deploy hook (which I've used to push the certificates via an API to Rackspace). This allowed me to do lots of awkward specific things for my setup.

I don't like their docs, but there is plenty of info in there:   --deploy-hook DEPLOY_HOOK



Pete Williamson

Carmen Data
0117 330 1439
On 23/04/2019 08:31:18, Keith Jackson <keith at> wrote:
This move to https really has me raging. I've got a load of small domains that used to run their own sites off the same core CMS. Now, with browsers messing about and redirecting to https when unwanted I've ended up having to put everything on a single root domain and redirect everything there to prevent having to spend a fortune on unnecessary SSL certificates (don't even get me started on the 3 days burned trying to get LetsEncrypt working in Azure before giving up and shelling out ?200 for a wildcard cert)

Anyway, rant aside, I normally do as follows...

http - -> https (for cert domains only) - - >
(although older site redirects probably went the other way around to be fair)
other - - >
(this allows a single wildcard SSL cert on all the different domains within the app)

Of course, if you are writing a URL in HTML itself rather than using http:// or https:// you can just (and should just) write // instead and the protocol used will be the existing protocol for the currently loaded page.
(quite possibly teaching the art of egg sucking to many on this list however)

Keith Jackson
The Ministry of Technology

From: Underscore on behalf of Oliver Kohll
Sent: Monday, April 15, 2019 10:51:49 PM
To: underscore at
Subject: [_] https://www

Dear _,

In our software, we detect URLs that people may type in (e.g. a web address, twitter or LinkedIn URL into an organisation record in a database).

If someone types, we automatically prepend https:// when turning it into a link, or when a routine on the server queries it, e.g. to extract an icon/image from it.

My assumption was that this would work pretty much all the time but from reports, it seems to fail quite often resulting in a certificate error like e.g. "NET::ERR_CERT_AUTHORITY_INVALID" from Chrome.

For many URLs, including some for the companies of subscribers to this list, what you type into the browser and the results are -> view website normally -> redirected to -> redirected to -> failure

I've been assuming as HTTPS becomes ubiquitous, this type of configuration (oversight?) will decrease but thinking about it, there also seems to be a trend towards deprecating the use of www. in domains which does indeed seem to be rather unnecessary as a prefix so maybe people aren't bothering.

I guess the options are
1) don't prepend anything. I'm not sure how serverside HTTP clients would react but could try it out (after trying, the Apache Java HTTP client at least doesn't like it)
2) prepend http:// - doesn't seem right but I guess that's what browsers are effectively doing
3) prepend https:// assume websites are gradually going to address things

I'm leaning towards 2, treating http as the default and letting the redirect to https which most sites should have work. If it's good enough for Google Chrome etc...

Would anyone do anything different?

underscore_ list info/archive ->
underscore_ list info/archive ->