Automatic SSL Certificates

With the release of DirectAdmin 1.62.0, support for Automatic SSL Certificates was added.  This will be a quick overview of the feature and a quick guide for debugging when needed.

Enable

For the Automatic SSL system to work, several flags must be enabled.
Run the following. All values should throw a value of 1:

da config-get letsencrypt
da config-get admin_ssl_cert_per_vh
da config-get admin_ssl_check_retries
da config-get mail_sni
da config-get admin_ssl_cert_on_create

Should any not show 1, set them, eg:

da config-set admin_ssl_cert_per_vh 1

Disable

The simplest way to disable the Automatic SSL certificate generation is to shut off the admin_ssl_cert_on_create setting:

da config-set admin_ssl_cert_on_create 0
systemctl restart directadmin

The admin_ssl_cert_on_create=0 will stop the creation of requests, but existing requests will continue to be retried. If retries need to be shut off as well (fully disable the feature for creation and retries), set da config-set admin_ssl_check_retries 0

Conditions

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.

Wildcards

1. By default, Domains and Pointers will try and use wildcards.  This saves the need for subdomains to get their own certificates.
2. Wildcard use dns so the zone must be local (or the local DA has control of a remote dns server).
3. Triggering a retry on a subdomain will always be http-only (never wildcard/dns).
4. 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=yes when 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).

Certificate Triggers

The system will attempt a certificate request based on the possible scenarios:

• User host creation/restoration (Domain, subdomain, pointer): These will create the .ssl request and .ssl.next_retry files 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:

admin_ssl_replace_all_expired_invalid=1  
admin_ssl_install_to_missing=1

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).

Certificates Index

The /etc/virtual/snidomains file is central to this system.

1. All User httpd.conf writes 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.
2. Cross-User certificates are allowed with the pro-pack: cross_user_ssl_cert=1 where A sub-domain User would be allowed to reference some other User's certificate.  Disabled by default.
3. 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
4. Exim already uses the snidomains file, and should already support wildcards.

Debug

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.