Concern about upcoming certbot redirect behavior

Client dev
#1

@certbot-devs

I just spotted this in a certbot output from one of our help-seekers:

Future versions of Certbot will automatically configure the webserver so that all requests redirect to secure HTTPS access.

This message was returned after the help-seeker had selected not to redirect to HTTPS.

I can't begin to state how much automatically-redirecting is "no bueno" for many people who come here. Often they aren't even aware that certbot will even touch their webserver configurations. To do so without warning in a fashion that more than a little frequently around here has resulted in broken webserver configurations seems ill-advised. I realize that the intent is to automate certbot as much as possible and ensure that users don't forget to redirect to HTTPS (which also occurs a lot), but taking away inherent choice from unaware users will cause preventable damage. I find that the automatic redirection certbot implements frequently does not work on more than basic webserver configurations (and in Apache uses RewriteRule instead of the far-more-efficient Redirect directive.)

1 Like
Must a separate virtual host be made for mail subdomains?
#2

And another thing...

Not prompting for which domain names to implement HTTPS redirects is not good either. Like, for instance, when that domain name does not even serve content over HTTP (like a mail server):

I suppose the only functional purpose I can conceive for serving HTTP content for a mail subdomain (that won't be used for webmail/webpage access) is to satisfy the ACME http-01 challenge.

1 Like
#3

I think this goes back to a fundamental design choice in the very early days of Let's Encrypt. It (specifically with certbot) is designed to be the Easy Button™, SSL for Dummies™, such that someone who hasn't the foggiest idea of what a webserver is, what a cert is, what TLS is, much less how any of it works or what they're doing, can get a cert for their webserver and configure everything behind the scenes. I wasn't convinced at the time that this was a good idea, and I think thousands (if not tens of thousands) of posts here have borne out my concerns.

One of the problems with this approach (by no means the only problem, but one of them) is that, when the software operates at a "for dummies" level, handling things behind the scenes, it isn't always going to do what you want it to do. There's an easy solution for that which more people should adopt: don't use certbot.

#4

Don't forget that posts here are going to heavily skew towards those with problems. People don't seek help when nothing goes wrong. So for the thousands who needed help, there are likely thousands more that worked without issue or well enough to not need help.

That said, web server configurations can be a complex beast. I have mad respect for the certbot team trying to make automating those configurations easy across multiple different web servers. And it's something I've deliberately avoided doing in my own client because I can't commit to the difficulty and constantly changing target.

2 Likes
#5

Hear! Hear! :+1:

I do want to emphasize though that doing things of a certain magnitude (like modifying someone's webserver configuration) without express approval (which would ensure awareness) is likely to garner quite a few angry responses. Keep in mind that we of this community are the frontline customer support of certbot. The problems incurred with configuration modification are one of the many reasons why I've so strongly advocated for a definitive divide between the acquisition and installation processes.

https://community.letsencrypt.org/t/how-i-wish-certbot-worked/138258

1 Like
#6

Don't think I have permission to view that post.

1 Like
#7

I'll move it to the #client-dev category.

Done.

#8

@griffin, thanks for taking the time to share your feedback. This is warning is quite old though as we made the change to have Certbot create HTTP to HTTPS redirects by default when installing certificates in our 1.0 release at the end of 2019. The decision to do this was based on our own user testing where the lack of a redirect caused problems and confusion for users.

I unfortunately don't have time to respond point by point to your concerns, but I just wanted to let you know we saw this and provide a bit more info. You can find discussions of things like why we use mod_rewrite instead of mod_alias on our GitHub if you're interested in digging into it further.

1 Like
#9

Thanks for getting back to us, @bmw. You can certainly tell how many people with old certbot versions we get around here. I think a lot of that has to do with people who can't (or refuse to) use the snaps version. There have been several rather vocal instances of backlash there. It is because of the "installation issues" that I always guide help-seekers through using certonly --dry-run until their processes are tuned. Then I guide them through installation with --keep. I would love your feedback on the suggestions I made here. They're reflective of the experience I've seen with help-seekers and the environments in which they use certbot.

#10

I've seen that thread (as well as your response to my feedback at https://community.letsencrypt.org/t/discussion-the-certificate-handbook/133296) and I hope to respond at some point. You've written a lot of suggestions which is great but there's only so much time in the day.

1 Like
#11

You do good work Brad. I definitely get it. For instance, I'm still waiting for an LE review of a PR I wrote over a month ago to overhaul the rate limit webpage. Things happen in time. :slightly_smiling_face:

1 Like
#12

Definitely one of my more artistic/antagonistic days. I don't think the humor was lost on you though. :upside_down_face:

1 Like
#13

I'm in the middle of overhauling my own ACME client, so I in my own way identify with some of the design growing pains. Speaking of... back to the coding block. Must... focus... :stuck_out_tongue_closed_eyes:

#14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.