More information about the Underscore mailing list

[_] https://www

James Bewley jamesbewley at
Wed Apr 24 15:37:30 BST 2019

I've been using Lets Encrypt under docker for several years now but I feel
your pain getting Lets Encrypt working on Azure.  I've wasted a lot of time
trying to get Let Encrypt working with Azure Kubernetes service.

I don't understand why SSL off-loading with Let's Encrypt isn't just a
standard feature of a load balancer.  It's pretty basic infrastructure that
you shouldn't have to manage these days.

Unfortunately I had to give up and buy a wildcard cert but was able to get
my Kubernetes ingress secured in minutes.

Have a look SSL2Buy if you need another cert, a wildcard cert is only $40.

On Tue, 23 Apr 2019 at 08:34, 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 <underscore-bounces at> on behalf of
> Oliver Kohll <oliver at>
> 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
> 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?
> Oliver
> --
> underscore_ list info/archive ->
> --
> underscore_ list info/archive ->