Hi there I'm just thinking about next improvements for the xmpp module. Next one might be support for lets encrypt. The webroot verification is not sustainable, because the xmpp server for domain.com doesn't have to be the webserver on domain.com port 80. So I have to go for the DNS verification. This way, I have to alter the dns zone for domain.com, adding the required validation key as TXT record. But again, in multiserver setup the xmpp server does not have to be the same as the DNS server. So, is there a good example on how (or is it even possible) to push a new job (add/alter TXT record) from the executing xmpp server script back to the ISP master database so the DNS server can pick it up?
There is a little work done/going on regarding DNS validation, which maybe you could contribute to or at least make sure you don't duplicate. Recently @ahrasis has been working on ISPConfig supporting DNS validation as an option in addition to webroot, so hit him up for status and maybe to help flesh out the implementation. As an example of how to manage the DNS records, the acme.sh script does support ISPConfig's api for doing just that (thanks to work by @sjau), though I believe that's bash, not php, so maybe not the example you need. There was some discussion/thought (I don't know about coding yet, but maybe?) on how to securely share secrets among servers in a multi-server install as a general, reusable function (in your case it would be the private keys), you might hit up @till and @florian030 on the status there. If you want to tackle the overall issue of requesting/updating certificates for the various services (for xmpp, but also https for control panel, email, ftp, even mysql and monit), that would be a very useful piece to put together. Right now there are numerous guides/scripts which all build/update it "outside" ispconfig itself, which works, but sure could be improved upon. Having the installer query if letsencrypt certificates should be requested, and automatically set them up, would be much better. Also have a handle in the server config page to disable/configure that. One issue to consider is how to specify all the domain names which should be included in a letsencrypt certificate (100 total allowed); I'd be glad to join that discussion if you are interested in tackling this little project.
The main problem with DNS verification for LE is that many ISPConfig users do not run their own DNS servers which makes it impossible for ISPConfig or the ISPConfig installer to set a token in DNS and setting a token in DNS during install is probably a general issue as single server setups do not have a dns record hosted for their hostname on 'themself' as the system is not even fully installed. I agree that we should try to find a solution for that but it will be probably not that easy, if would would want to set up DNS verified LE certs during install, then we will probably have to pause the install, explain the user what he shall do at his dns provider (which many users won't even understand as you would have to provide instructions with probably screenshots for many dns hosters), then let him come back and resume the install after DNS has been propagated, then retry to verify the LE token etc. I fear this will cause a really high failure rate for the installs and may make ISPConfig uninstallable for the nonprofessional user. In my opinion, we should build the http verified token approach in the installer instead of the dns way and maybe offer dns for expert mode only. In regard to the encrypt functions for shared data, I've looked into that already bit it's not finished yet. But there will be definately reversible encrpt/decrypt function in ISPConfig 3.2.
Some thoughts: the installer could ask if you want letsencrypt or generate a self-signed cert (or option to do nothing if a cert files are already on the machine); if you choose letsencrypt, it might need to prompt for an initial list of names to include in the certificate (which could be updated later via the gui), and will default to webroot with an option to use DNS verification; if DNS verification is selected, the public key and brief "how to" message is printed (including a url for more info), and a note that the install will use a self-signed certificate until that is done, and the install sets up a self-signed cert and continues on, setting a "try dns verification" flag for the server. Later on, when a cronjob runs and DNS verification succeeds, the self-signed certificate is replaced. For that matter, the same process could be done for webroot (ie. install a self-signed cert, set a flag for "try webroot verification" and continue on). As for additions/ideas in the ISPConfig interface, the server config could support multiple "server certificates", and each service (mail,web,db,xmpp) can specify which server certificate is used. Each "server certificate" definition includes a list of names to be included, and maybe convenience checkbox for the server's fqdn (and reverse dns name?). That would allow creating one server certificate with a few server-specific names plus 95+ "mail.client1.com" type names for mail service, and a second with 95+ "ftp.client1.com" names for ftp, one with "db.client1.com" names for mysql, and "xmpp.client1.com" names for xmpp. That wouldn't fix the issue of having enough names in a certificate for large installs, but it could help smaller installs, and even on larger installs there might be a few specific/more important domains to be included in the certificate. And to test all those names for validity before requesting a certificate, probably the same checkbox as is used now could work, to test dns or not.
