getssl
getssl copied to clipboard
srvrco
update problem due to domain verification with https RewriteCond
getssl checks the acme challenge via http request before creating a new certificate ; that failed when a previous script had rewritten the apache2 config files such to automatically upgrade http accesses to their https counterpart such that all http requests are actually https requests - but that fails if the certificate for this https site does not include the domain yet, and it does not include the domain yet because the domain has not yet been verified... circular bootstrapping problem.
It is resolved by commenting out all RewriteRule statements in the apache config files for a new domain that is to be added.
Not sure what is the best way to address this in the getssl script. The problem should at least be documented. Options might be to have the getssl script modifying the apache config files such to temporarily disable the RewriteRule statements for the domains that are yet to be verified, to to bypass this step and to install the certificates anyway - a subsequent https access will then succeed.
Just a couple things. One, I am not the author of getssl but I use getssl and I also volunteer at Let's Encrypt support. That said:
getssl does not check the acme challenge - the Let's Encrypt server does that. The LE server always makes a request to HTTP for http challenges. It will only try https if your server redirects it.
getssl does not modify your server config. If your server conf cannot process an https request you should not redirect from http to https.
The Let's Encrypt server does not validate the kind of certificate sent by your server to it during one of these challenges. For a new server setup, you can create a self-signed cert or even use an expired cert until you receive a fresh LE cert. Or, just avoid redirecting http to https until you have a cert you wish to use (as you did).
Ah ok, that explains some things. The problem was that my old certificate did not yet include the new (sub)domain, but the only error message that I got was a timeout message, mentioning it was "probably a firewall issue". But it was due to this redirection problem with a yet invalid certificate. It was a former certbot that created those redirections, so I was not even aware of it. Took me two days to figure out what was actually happening. So anything that would ease this situation for future users running into similar problems could be beneficial. Maybe just adding a "grep RewriteRule /etc/apache2/sites-enabled/*" could help to point out such a problem if domain verification failed.
The "possible firewall" problem was not related to an invalid cert. As I said, the LE server does not validate the cert you send it. There must have been some other comms problem that prevented connect (maybe other faulty/missing ssl settings unrelated to certs). That error occurs when the LE server cannot reach your site - it has not even seen any cert from it. These sorts of problems are routinely dealt with at the Let's Encrypt support forum.
getssl is not even aware of what kind of server you are running (*) to do a grep against its config. And, there is nothing wrong with redirects as long as the location you redirect to can respond to requests. I appreciate your frustration but that is part of the learning process.
getssl is best for people who are comfortable managing their own server configs. That is a major reason I prefer it over, say, Certbot. You are now further along in becoming comfortable :) And, perhaps this thread will help future people when they search issues.
(*) You specify the location for http challenge files in the getssl cfg files. You also tell it the (optional) command to reload your server. getssl stays blissfully unaware of your server software and has no need to auto-detect it. That would be no small feat since systems can have more than one installed and active. Certbot, for example, requires you to tell it which server to configure. getssl has no such setting.