add rewrite rule for Let's Encrypt certificates

[vapier]

The LE tools need access to a stable path to automatically obtain
certificates, so add a rewrite rule to allow it.

[welcome]

💖 Thanks for this pull request! 💖

We use semantic commit messages to streamline the release process and easily generate changelogs between versions. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix if it doesn't have one already.

Examples of commit messages with semantic prefixes:

• Fixed #<issue number>: don't overwrite prevent_default if default wasn't prevented
• Added #<issue number>: add checkout functionality to assets
• Improved Asset Checkout: use new notification method for checkout

Things that will help get your PR across the finish line:

• Document any user-facing changes you've made.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[jerm]

Looks good to me:

• Encourages people to use TLS by making it easier to use LetsEncrypt
• LetsEncrypt is already so widely used that having this as a default makes sense
• Anyone not using LetsEncrypt won't even have this directory to access

I don't see a downside

[snipe]

Thanks, @jerm !

[snipe]

@vapier thanks very much for this :)

[welcome]

Congrats on merging your first pull request! 🎉🎉🎉

[snipe]

(This screws us on the demos though, since I have some manually added rewrite rules, mostly to block bad actors at the IP level - and could possibly interfere with other people's customized rewrite rules.)

Do we need to worry about adding this dir to any gitignores?

[jerm]

hmm.. .gitignore would be helpful but not strictly required, as .well-known will show as an untracked file, but won't conflict since we're not including anything.

[jerm]

(This screws us on the demos though, since I have some manually added rewrite rules, mostly to block bad actors at the IP level - and could possibly interfere with other people's customized rewrite rules.)

not sure i follow.. wouldn't local customizations be a problem any time you update the software?

[snipe]

Yes, but we don't generally update that file (other than on the demo, again, to block bad actors). It shouldn't cause any problems, but we should underscore the fact that upgrading users will need to pull their own htaccess from a backup or from the git stash that happens if they use the upgrade.php process.

[snipe]

(We don't deploy via git on the demos - we use DeployHQ, so we bypass the git stash part, so it means that I have to remember to reapply those files that get overwritten.)