Directadmin Docs

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.

Enable

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 config | grep letsencrypt=  
./directadmin config | grep admin_ssl_cert_per_vh=  
./directadmin config | grep admin_ssl_check_retries=  
./directadmin config | grep mail_sni=

Should any not show 1, set them, eg:

./directadmin 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_check_retries setting:

/usr/local/directadmin/directadmin set admin_ssl_check_retries 0  
service directadmin restart

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.

Last Updated: