Josh (the blog)

Hey there. I’m Josh, a SydneyCanberra-based maker of Internets. I don’t update this very often.


@joahua

LetsEncrypt + CloudFlare + Apache 'failed authorization procedure'

Finally got around to playing with LetsEncrypt this evening. I was naively copy-pastaing my way through a tutorial when I ran up against this error.

Failed authorization procedure. www.example.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 104.27.178.157:443 for TLS-SNI-01 challenge, example.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 104.27.178.157:443 for TLS-SNI-01 challenge

The IP in the error belongs to Cloudflare, which was already active and providing ‘flexible’ (i.e. illusory) SSL. [1]

One way to fix this is to make a DNS change to point directly at your origin server (your own IP), instead of the CDN, while you provision the cert. But half the point of LetsEncrypt is that you get readily automated and cycleable certificates, which big scary DNS changes would get in the way of. Not to mention that DNS changes are typically slow/multistage/relatively hard to script.

Thankfully, LetsEncrypt are smart folks and have another option.

Enter --webroot.

sudo letsencrypt --apache -d example.com -d www.example.com --webroot --webroot-path=/var/www/html/ --renew-by-default --agree-tos
> Too many flags setting configurators/installers/authenticators 'apache' -> 'webroot'

Did I mention I was using Apache?

The copy-paste tutorial I was following used the --apache switch as a way of, I guess, automagically configuring a virtualhost. I broadly trust that LetsEncrypt will have saner defaults than whatever other DigitalOcean tutorial I used to provision the box in the first place, so that seemed like a good idea. Only, of course, it wasn’t compatible with the --webroot switch.

But, eventually, this did:

sudo letsencrypt --installer apache -d example.com -d www.example.com --webroot --webroot-path=/var/www/html/ --renew-by-default --agree-tos

Seems like --apache is shorthand for --installer apache, which is somehow sufficiently differentiated from --webroot to not throw errors. Don‘t know what I’m doing deeply enough to file a bug yet so throwing this blog up for a hopefully searchable solution in the meantime.

  1. This has been written up dozens of times, but to summarise the issue:

Browser talks to CDN talks to Server.

Browser to CDN is secure. CDN to Server is insecure.

So we’re trying to fix that last mile (which, of course, still leaves the “CloudFlare can MITM half the Internet” issue… but that’s a bit beyond my immediate threat model).

Scraping active Optimizely experiments

Need to see what’s running?

I think Optimizely might’ve done something to make this tricker as an optional project setting, but it’s handy to be able to debug what’s running and possible splits.

Object.keys(optimizely.allExperiments).map(function(item){
item = optimizely.allExperiments[item];

if (!item.enabled) return;
console.log([item.name,'\n',item.variation_ids.map(function(v){
    return "\t" + item.variation_weights[v]/1000 + "%: " + optimizely.allVariations[v].name;
  })].join(''))
})

Paste in console.

Fixing a Magic Button MBTX4 remote (which is really a Neatrol Systems 4Ch RFAND Tranceiver)

Our garage remote died recently. We subbed the battery, and nothing improved. Stood closer, nothing improved. Sporadic successes were very-much outweighed by failures.

The base station/”receiver” (it’s actually a tranceiver, I think? If you want to learn more about this than I did, KeyLoq would be a good starting point) in our little block of four has been known to have some problems, but the sporadic failures and our pretty comical attempts to hold the remote at different angles, out windows, bashed-sideways, bashed-frontways, etc., were yielding poorer and poorer results.

Anyway, an afternoon prodding the thing got us to “oh the button’s probably dead”. So much for those new batteries.

At least in our situation, a four-button remote is a pretty useless thing - there’s only one gate to control. Turns out the numbering on the front of these things doesn’t even line up with the PCB - we hit “2”, which always confused me no end, but this is really pressing button 1 on the circuit.

Button 1, in this case, was doing nothing at all.

Replacement time!

The PCB’s pretty generously spaced, probably because no-one wants a remote so tiny it gets lost. The surface mount buttons are pretty easy to work with. I ordered this pack of 20 buttons from an eBay seller (described as a “20pcs 6x3x4.3mm SMT SMD Momentary Micro Tact Tactile Push Button Switch” in the very likelihood the listing has vanished by the time you’re reading this… eBay, stop the bitrot!) for about $5 having measured up the button as being, well, vaguely that size. The buttons on my remote were black and these were white, but hey, it’s behind a piece of rubber anyway. If anyone needs 19 SMD buttons and is in Sydney, holler at me - they’re probably in a drawer somewhere.

Removed, faulty, switch Side-by-side switches. Doesn't matter if you're black or white. New switch, poorly soldered, in situ.

I realised while I was popping off the old button and soldering on the new that I actually didn’t need to order any buttons at all, of course.

If you, like me, only use a single of your four remote buttons… just swap the bad one for a good one! My soldering is shocking but the original SMD work was pretty tidy and easy to get things on and off. The good news is it’s a spacious enough board you probably don’t need to worry too much about melting the wrong thing.

Anyway, yay, working remotes again!

Jekyll, .well-known and other dotfiles

Not that this blog is used for much, but I hit this while trying to add a file under .well-known and realising I couldn’t get the directory to show up.

As this is hosted on Github Pages (and I hadn’t published for ~2 years), I wondered if adding a static file wasn’t enough to trigger a publish. Turns out GH Pages is fine, the issue’s how Jekyll handles (or doesn’t) . prefixed files/dirs.

The solution is to add this to your config.yml:

_config.yml

include: [".well-known"]

Jekyll actually documents this pretty clearly (search “Include” on that page) but I found mention of it on a Keybase issue first.

Given their documentation is focused on .htaccess files (haven’t used those/Apache for a while!) I thought I’d document here to optimize more for the search terms I was using!

Jekyll

First update in quite a while… but worth noting this blog is now powered by Jekyll after a pretty bad run of security things with WordPress (my fault: not keeping it up to date, their fault: security holes every other day).

Good news is everything is static and Github Pages hosted now. Comments have gone to Disqus (for better or worse), and analytics stays on GA (I just upgraded their circa 2007 Urchin tracking JS). Love it when stuff starts to work.