Let's Encrypt DNS-01 authentication

I have a site that I would like to run on a non-standard HTTPS port. Does ISPConfig support using DNS-01 authentication with certbot? If so, how do I set this up?

 

Not yet, but there are a few attempts. Nothing works out of the box though:
https://git.ispconfig.org/ispconfig/ispconfig3/issues/4202
https://pypi.org/project/certbot-dns-ispconfig/

You could use acme.sh for that (also here you have to set it up manually, but that is easy: First attempt will fail, than you can edit the config file to your needs and use dns validation)

Be aware, that all of the shown workarounds can break your letsencrypt installation. Depending on your knowledge, it might be easier to use a dummy web at Port 80 to issue the certificate and use the non-standard port for your website

 

No, not yet, but you can try the tips I posted in here if it is relevant your needs: https://www.howtoforge.com/communit...via-certbot-dns-validation-in-acme-v02.79049/

 

Also looking for DNS-01. Will watch this thread and others.

 

I am using it with acme.sh. Switching is difficult, but if you install it for a new system it should work. (Looking at the other threads, you already tried/did this)
You can not configure it via the web interface, though.
The ISPC acme.sh implementation is edit-friendly. ISPC just does the initial configuration and then everything is done by acme.sh itself. So you can let ispc write the configuration and then edit it to your needs (like switching to dns challenge). Do this if you want this for a single domain (or want something else changed, like ECC certs or wildcard..)
If you only want dns challenge, you can just add "--dns dns_cf" (in this example for cloudflare dns) to line 77 of https://git.ispconfig.org/ispconfig/ispconfig3/-/blob/develop/server/lib/classes/letsencrypt.inc.php
from

Code:

[...] ' . $letsencrypt . ' --issue ' . $cmd . ' [...]

to

Code:

[...] ' . $letsencrypt . ' --issue --dns dns_cf ' . $cmd . ' [...]

(untested)
For sure you have to configure dns challenge first via: https://github.com/acmesh-official/acme.sh/wiki/dnsapi
Then all your future certs will use DNS challenge. Be aware, that the letsencrypt.inc.php file will be overwritten by ispc updates in the future. (But the acme.sh config files will stay as they are)

 

Interesting. I guess for acme.sh we can check if the respective DNS API exists in the bash export command, and if so add the respective dns command line there, otherwise it is simply empty to use webroot as default. Skeleton code in my mind would be:

$dns_api=get from somewhere e.g. CF_Token|CF_Zone|CF_Account for CloudFlare
$dns_command=get from somewhere e.g. '--dns dns_cf';
$dns_check=exec("export | grep -E $dns_api");
possibly domain check as well
if all strings found and domain is checked and authorize $dns=$dns_command; else $dns='';

*get from somewhere means it could be maintained elsewhere like database or lib file.

 

I support the idea to implement the DNS challenge! IMHO it would be enough to have a checkbox for the user to switch. If activated, ISPC could either require the user to configure dns as the acme.sh faq requests or ask for the config and write directly to "~/.acme.sh/account.conf". Requiring the admin to use the command line might be the easier and more future-proof version. So the admin would fill in a field with the api like "dns_ispconfig", and a reminder to set the exports on the command line (only needed for setup). ISPC could also set the exports, but I am not sure if that can cause a security problem.

The thing is: The "export api" is only needed for the first time. Then the credentials (if successful) are stored in the config file (~/.acme.sh/account.conf) and reused. So after a reboot, the exports are gone, but the config still works. The variables are directly written to the config with a preceeding "saved_". eg:

Code:

SAVED_NC_Apikey='xyz'
SAVED_NC_Apipw='securepw'
SAVED_NC_CID='123456'

In theory, every certificat can use a different authentification mehod. Could be difficult to support this. However, the config for the cert is already managed by acme.sh, so in principle, ispc only needs to know about this when acquiring the cert for this domain for the first time. It would be enough to ask for the api type (like "dns_ispconfig" or "dns_cf" or empty for webroot) and remind the user that he has to export the configuration on the command line before. Acme.sh takes care of the rest.

 

Security and privacy are among my worries too actually and I am not sure whether admin can do it for their client for that reasons, though server with sole user has no problem with that.

I am also not sure if client can export themselves, so most probably root could do it, if they cannot.

But if client with ssh can do export themselves but I am not sure how root can trespass to clients' area and get that export clients' data, but may be this can be added in data privacy agreement etc.

Plus I am also not sure how multiple export of dns api data from various clients from multiple of domains will clutter the system or will work under acme.sh dns challenge and to what extend.

I am clear about certbot as dns api data may be kept in a secret file can be kept inside specific directory as suggested or in their own website /ssl folder with proper ownership and permission for owner and system respectively.

I will research deeper as this is one of my main area of interest. As usual, no promise whatsoever.