Automatic SSL Certificates
With the release of DirectAdmin 1.62.0, support for Automatic SSL Certificatesopen in new window was added. This will be a quick overview of the feature and a quick guide for debugging when needed.
For the Automatic SSL system to work, several flags must be enabled.
Run the following. All values should throw a value of 1:
cd /usr/local/directadmin ./directadmin c | grep letsencrypt= ./directadmin c | grep pointers_own_virtualhost= ./directadmin c | grep admin_ssl_cert_per_vh= ./directadmin c | grep admin_ssl_check_retries= ./directadmin c | grep mail_sni=
Should any not show 1, set them, eg:
./directadmin set admin_ssl_cert_per_vh 1
The simplest way to disable the Automatic SSL certificate generation is to shut off the
/usr/local/directadmin/directadmin set admin_ssl_check_retries 0 service directadmin restart
The domain in question (and all of it's sub-hosts) must be using the
Shared Server Certificate option on the SSL Certificates page, which is the default for new domains.
- By default, Domains and Pointers will try and use wildcards. This saves the need for subdomains to get their own certificates.
- Wildcard use dns so the zone must be local (or the local DA has control of a remote dns server).
- Triggering a retry on a subdomain will always be http-only (never wildcard/dns).
- Should a wildcard request fail (eg: DNS does not yet resolve to this box), it will auto-fallback to an http-based request. It will not change the domain.com.ssl request file, which would remain
wildcard=yeswhen requested. If the fallback also fails, the next_retry is set to a future time (
admin_ssl_poll_frequency), and the original request-type is made at that time (eg: it would try the wildcard again).
The system will attempt a certificate request based on the possible scenarios:
- User host creation/restoration (Domain, subdomain, pointer): These will create the
.ssl.next_retryfiles for that specific host.
- Manual Triggers: Used if a host already exists and the User wishes to switch to the new system.
- Pro-Pack options:
These are disabled by default and we'd typically encourage you to keep them disabled as they poll every minute and can create many requests (might be fine for smaller hosts, if needed).
/etc/virtual/snidomains file is central to this system.
- All User
httpd.confwrites do a lookup for their host here (assuming "Shared Server Certificate" is selected). Subdomains look for their exact match, and fallback to looking for a *.domain.com match. A pasted cert/key will always use that cert/key.
- Cross-User certificates are allowed with the pro-pack:
cross_user_ssl_cert=1where A sub-domain User would be allowed to reference some other User's certificate. Disabled by default.
- Dovecot sni domains files are created for domains and pointers (never subdomains), and fill the host values based on the host values within the certificate
- Exim already uses the snidomains file, and should already support wildcards.
You can manually see what the
Ssl::admin_poll is up to by running it manually wish the SSL debug level:
echo "action=ssl&value=admin_ssl" >> /usr/local/directadmin/data/task.queue.cb /usr/local/directadmin/dataskq d1245 --custombuild
It will hunt for any relevant next_retry files (or the pro-pack triggers), and attempt those requests.