After starting Certbot, my setup failed with the "Could not reverse map the HTTPS.." message.
Now I do not want to discuss my specific setup here, as many other users with the same problem did. It seems that the Certbot-Automation only works with completely fresh and untouched Apache config files, even a wrong line ending or order of commands may lead to failure.
What I question here is the concept of certbot to automate the whole installation process.
Linux is often used when people want to learn and control their server, not for the least key presses to achieve a function.
What does make sense for a bot are the steps unique to the specific task:
Register at letsencrypt
Get and store the key files
But what a user will often do - and understand - himself:
Change the server configuration files
So I propose for certbot per default not to change apache conf files, instead output the recommended lines for apache *.conf, like:
SSLCertificateFile /etc/letsencrypt/live/www.example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
Yeah, certbot offers plenty of options, including trying to manage your config for you, or not doing so. Now, certainly there are plenty of poorly-written tutorials out there, but I think certbot itself offers plenty of flexibility for the various ways system administrators might want to use it. (And you might be surprised just how many "reluctant administrators" there are out there who manage a server for their web site but don't really know how to or want to.)
And if certbot doesn't meet one's needs, there are plenty of other ACME clients out there which might fit what you're trying to do much better.
The concept of Certbot is to facilitate all kinds of users, including relative novice users who might not be capable of reading the Apache documentation on how to install the certificate.
Certbot has plenty of methods to not try to install the certificate. Usage of the --apache option (or the separate -a apache / -i apache options) is completely optional.
I encourage more experienced computer users to read the Certbot user guide to figure out which options are best suitable for them. But I do not think Certbot should change its defaults (which frankly only is that it defaults to the run subcommand instead of the certonly subcommand).
Yet they have the follow on discussions of certificates are issued (and downloaded somewhere) but the sever isn’t serving the issued certificates. Because the OP doesn’t know how to configure the server to utilize the issued certificates.
Doubt it. We'd have more threads here on the Community in that case. Those problems are probably edge cases and novice users probably have pretty default configurations anyway.
Comparing with how many Certbot users are out there? Not that many.
Can you back this up with statistics? Please also compare this with threads like "I got a certificate, but my website is still insecure!!!" by users inadvertently using certonly because they read that on the internet somewhere..
This is unfortunate and likely to lead to additional failures. Why Automate the Apache Setup...
Because it works.
Sorry that is a serious issue. Frankly. There is much more you are not sharing here. This is an issue which if you are here on the forum you have to deal with,
CertBot does change the SSL config. If you do not want that you should consider changing your ACME client. Even most of those will attempt to make sure your configurations are up to spec.
Linux is used when people want to secure their server. Nothing else.
What understanding do you have with your operating system? Please discuss this with the expert volunteers here.
Please advise. Or otherwise .... Live with it.
The root issue here seems to be around apache config being misinterpreted or potentially mangled. That seems like an Augeas problem (which certbot uses).
Really though, if you're a power user (i.e. you actually know how to edit your apache config and setup https, unlike many users) you can:
restore from backup if your config gets hosed (power users always have backups)
fix problems in the config manually (because you can see the problem)
just use the webroot method
I agree if you're working manually/interactively there could be a yes/no question as to whether you want certbot to update the config or just show you the changes but by default editing files themselves (correctly) is too much work for average users.
If you have a good understanding of http config and apache config in general you are in the top 10% of folks with admin rights, the vast majority of people who look after web servers for small organizations have a completely different job (their "real job") and just got given the task, they are not sysadmins and they haven't even read an o'reilly book.
I question that.
Let's look at the language of that error alone:
"Could not reverse map the HTTPS."
How exactly would the script seek to "reverse map" the service?
Bloated language.
What it tries - more or less successful - is read the apache conf file/s, add the new lines for Key / cert and restart the web server.
If one was interested in making it work transparently, one would describe the concrete problem .. like "iiritating order of directives".
Secondly, insisting on a problem-solution dialog in this thread shows only that you are not interested in conceptual debate; so you may be wrong here, in this thread.
The solution I proposed is in the fist message - just output the lines:
SSLCertificateFile /etc/letsencrypt/live/...pem
...
There are hundreds of ACME clients serving different use cases. Of the "major" clients representing the most users, Certbot is considered to be the most popular because it is a general purpose client that was specifically designed to automate and streamline the http->https onboarding process by altering the configuration files of the most popular web servers. Like many of the ACME Clients designed to function within Control Panels, it is specifically designed to be used by end-users with limited or no sysadmin knowledge.
I am typically more blunt than other people who post here: this suggestion is beyond absurd and reeks of entitlement. Certbot is one of the most deployed software projects in the world that has been working as intended for millions of users; LetsEncrypt is currently securing more than half the internet, and Certbot is the most popular client by a wide margin. You essentially are suggesting the core functionality, purpose and mission of an established and widely deployed software to be gutted and replaced with entirely different ones simply due to your personal preference.
If you don't like the way Certbot operates, select another client or invoke Certbot with other commandline options (as suggested above). Otherwise, I hope you can one day realize how absolutely ridiculous the suggestion to make HTTPS onboarding more-complicated is.
In any event, while Certbot likes to point people here for help, their maintainers and developers do not frequently visit. Most of the community helpers are involved with other ACME clients, work on ACME servers, or are ACME integration consultants.
The purpose of the "Feature Request" section is for LetsEncrypt features, and to a lesser extent the ACME Protocol and Boulder implementations (both have dedicated channels elsewhere).