Hi, I messed up with one web site and I need to install wildcard LetsEncrypt SSL on it. As ISPConfig does not support it yet (https://git.ispconfig.org/ispconfig/ispconfig3/issues/5002), I will have to install it manually. I am running Certbot 0.27.1 version on Ubuntu 12.04 + Apache. Please, need advice on the following: Should I DISABLE LetsEncrypt SSL on this particular web site, or should I leave it? Should I run with --certonly switch, or should I let certbot install and configure Apache for me? How will this impact ISPConfig ControlPanel functionality? Will ISPConfig's chron auto-renew this wilcard ssl too?
1) Good question, have not tried what you want to do. But probably leaving it on should be ok, as long as certbot replaces the cert without changing the name. 2) You have to use DNS auth as that's the only way to obtain a wildcard cert from LE (and the reason why you can't do it with ISPConfig yet). 3) use certonly. Certbot is not able to rewrite apache config without breaking it as it does not take in account that an apache config can contain unique elements which can not be copied, so don't try it.
Huh... after struggling with manual DNS editing to match TXT _acme-challenges for 8 hours (I need to mail new challenge to tech, he then forwards it to admin, which approves and enters it manually...and then I find out Certbot timeouts, and let's do it again by adding _acme-challenges...BTW, you need to ADD new _acme-challenges, not replace old ones, that I learned hard way!), I've finally got approved and SSLs generated. But they are saved in folder, ending with -0001: Your certificate and chain have been saved at: /etc/letsencrypt/live/domain.org-0001/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/domain.org-0001/privkey.pem What you think - I moved them to /domain.org/ and replaced existing ISPConfig's generated LE files, but will they get renewed automagically with ISPConfig cronjob? Or worse, will they get replaced by ISPConfig's SINGLE-DOMAIN ssl, or will they stay WILDCARD?
And that's the reason why we have not implemented DNS auth yet, have to find a way that's usable for the normal user and to reimplement SSL in general to support such a multi step thing where you can stop the process and continue for days. This will break LE. Instead, change the symlinks in the ssl directory of the website to point to the 0001 version of the certs.
Weird...seems like ISPConfig or some other robot came to the same idea by itself, because after I copied all certs from /domain-0001/ site to /domain/, few hours later all those certs, that I manually copied over to /domain/ changed from FILE to SYMLINK, pointing to 0001 archive site. I did this today morning: Code: root@server:/etc/letsencrypt/live/domain.org# ls -al total 12 drwxr-xr-x 3 root root 4096 Oct 18 21:38 . drwx------ 13 root root 4096 Oct 18 10:50 .. lrwxrwxrwx 1 root root 50 Oct 18 11:01 cert.pem lrwxrwxrwx 1 root root 51 Oct 18 11:01 chain.pem lrwxrwxrwx 1 root root 55 Oct 18 11:01 fullchain.pem lrwxrwxrwx 1 root root 53 Oct 18 11:01 privkey.pem Then I did nothing, but restart apache, and now I find in the same folder this: Code: root@server:/etc/letsencrypt/live/domain.org# ls -al total 12 drwxr-xr-x 3 root root 4096 Oct 18 21:38 . drwx------ 13 root root 4096 Oct 18 10:50 .. lrwxrwxrwx 1 root root 50 Oct 18 11:01 cert.pem -> ../../archive/domain.org-0001/cert1.pem lrwxrwxrwx 1 root root 51 Oct 18 11:01 chain.pem -> ../../archive/domain.org-0001/chain1.pem lrwxrwxrwx 1 root root 55 Oct 18 11:01 fullchain.pem -> ../../archive/domain.org-0001/fullchain1.pem lrwxrwxrwx 1 root root 53 Oct 18 11:01 privkey.pem -> ../../archive/domain.org-0001/privkey1.pem Anyways, I changed symlinks in /var/www/domain.org/ssl directory to point to 0001 Wildcard SSL cert and bundle. Let's see what happens.
ISPConfig contains some code to work around many weirdnesses from certbot by trying to search for matching certs even if certbot placed them into new paths
BTW... one other idea I read about and was just about to try it regarding DNS auth for Wildcard LE SSL, was by asking customer to create one single CNAME record _acme-challenge.hisdomain.com, pointing to my own DNS server CNAME _leacmechallenges.myserver.com. Then I would mess with challenges on my own DNS with ease, without the need to disturb domain owner. This should work. Discussed here: https://news.ycombinator.com/item?id=17698930
I found that there are various ways to create wildcard certs and I already discussed a few in Create Lets Encrypt SSL Certs via Certbot DNS Validation in Acme v02 though I haven't specifically discuss the use of nsupdate to securely and remotely update the TXT records simply because ISPConfig uses its database for its dns server. I haven't come out with the best solution yet however the last one I planned to propose to ISPConfig but haven't attempted yet was: 1. To add to ISPConfig dns setting page a tick button to create TSIG key (something like DNSSEC) (in Bind folder); then 2. To grab and add the created TSIG key to ISPConfig database; then 3. To add dns validation option box in website settings page (also involves adding to ISPConfig database); then 3, To modify ISPConfig LE plugin to automatically use dns validation if this key exist and dns validation box is checked at website settings page with or without wildcard; and 4. To add warning upon saving if the domain dns TSIG key is not found in the database and uncheck the dns validation option box. Problem I expected is multi domain in one certs attempted via subdomain or aliasdomain which I thought could be reduced via similar warning in number 4.
Using CNAME like that could allow the use of wildcard certificates for domains with externally hosted dns, which could be a nice thing to design in from the beginning. It would require a setting in ISPConfig's SSL setup to use this feature/mode, and a text field to enter the target hostname (which is a name that ISPConfig can control DNS records for). You would not want to use the same target name for each client domain, they should each have their own for scalability. So walking through an example with this setup: - client has domain client1.com with external DNS - client creates _acme-challenge.client1.com CNAME record to a canonical name under ISPConfig dns control, say client1._le.server1.webhost.com - in ISPConfig SSL tab, client enables SSL, using LetsEncrypt External DNS mode (or whatever it's called), and enters "client1" as the hostname to match the CNAME record (the _le.server1.webhost.com part cannot be selected or changed by the client) - ISPConfig proceeds with DNS based validation (request validation code, adds client1._le.server1.webhost.com TXT record with that code, (possibly does the same for other hostnames if the certificate contains multiple names), waits some time for DNS propogation, requests/issues the actual certificate, handles failure if needed, and lastly cleans up the TXT records from DNS)
If I understand correctly, this is kind of the other direction, ie. have ISPConfig use nsupdate to a client's external dns server? That could work, but I imagine would not be as useful for most customers; anyone using an external dns system should be able to add a CNAME record (eg. in registrar's control panel), but only those operating their own external servers are likely to be able to add TSIG keys on the other end to set this up. But I may have misunderstood the above, too.
TSIG key is used only if you don't need to use ISPConfig database for dns server; otherwise, using its database would be preferred. Based on my test, there is no need to use database to apply dns challenge either using certbot dns_rfc2136 plugin or nsupdate with TSIG key as the txt records can always be deleted after LE SSL certs are issued. For each renewal, new LE validation token will be issued, so any txt records which contains the token can only be used once either for LE certs issuance or renewal. And for the time, I can only figure scripting a bash script to capture the token(s) for LE validation and still finding best ways to use php for that (as I am quite slow in mixing them together).
Correct, the use case would function to add a txt record without the database involved, but it is probably better to use the database when you consider mirrored servers. I recently setup a bind server using nsupdate method from a pfsense firewall, which uses acme.sh under the hood. It has a gui config interface if you care to look at it as a functioning example of the interface elements. Of note, each domain name in the requested certificate has a key and server listed, and also supports the CNAME setup mentioned above.
May be, and I already suggested it in my earlier post above but have not attempted to do it yet, because I think that idea is still flawed. I mean do we really need a TSIG key if ISPConfig database is to be used; since we just need that LE tokens for validation to be temporarily added as TXT records. I think may be we can just grab LE validation tokens, pass them to ISPConfig database as domain txt records, update the zone file, validate them, and finally remove that txt records after LE certs are issued; that would suffice. Unless, we are talking of allowing any ISPConfig dns server user to create and use the TSIG key to update certain records in their domain zone file temporarily without updating ISPConfig database; is that it? Anyway, for the time being, I'd prefer to finalize dns challenge for ISPConfig first before any attempts to add support for other dns servers. And, I never found any needs to use cname records though I did read somewhere about it; so why that cname is necessary for any of this?
No, not when considering only ISPConfig controlled dns, there's no need for keys; they could be useful in other scenarios (updates to or from non-ispconfig dns servers). There are two scenarios, that is one of them. This is exactly what my recent pfsense setup did, and it allowed DNS based validation to work for an external device, ie. the firewall was able to obtain a letsencrypt certificate using dns validation, and the dns servers happen to be ISPConfig dns servers. A few gui fields/support for this could have setup they key for this, and is precisely what a client would need if they were to use this type of setup. The other scenario where keys would come in to play is with external DNS servers, when a customer eg. hosts their website on an ISPConfig server, but DNS is not. If the customer were able to setup a key (on both ends), it could allow ISPConfig to use dns validation to obtain a letsencrypt certificate for the website. For that matter, acme.sh supports quite a few remote dns api's (including nsupdate), and this setup could be made to work for more methods than just nsupdate to configure the remote dns servers. Yes, there's some overlap in the two, but full support in an enclosed ISPConfig would be a good start. CNAME records aren't needed for a domain that is fully hosted on ISPConfig (dns and website (and eventually email?)); it would allow another means to accomplish the second scenario (just above), when a customer uses external dns servers. Instead of setting up keys (or even the various acme.sh supported remote api's), the customer would add a CNAME record at the remote end, which is simple enough for "anyone" to do, then ISPConfig could add TXT records to a domain for which it controls dns, and be able to issue certificates for a client website.
One issue to keep in mind on this (down the road, if it's implemented) is the SOA serial number - each time the client would update their zone via nsupdate (eg. 2 times for every certificate request at minimum), the serial number automatically increments. I believe right now ISPConfig generates and explicitly sets the serial number, so it would need a means to look up the current serial number from the zone (probably it would "freeze" the zone, look up the serial number, add/manipulate records including updated SOA, then "thaw" the zone, so there are no conflicts). Another related point, my guess is it generates a complete new file currently, and that would have to be modified to eg. add/delete known records, and ignore others.
I will need time to digest but if you are talking about LE ssl certs for any ISPConfig servers, the latest LE4ISPC script already covers that via certbot standalone approach. I will only be focusing on dns challenge for domains and not servers for this.
