Automatic SSL Certificates

Enter Your Query:
Use '%' for wildcards and quotes for "exact phrases"

Top Level » SSL

Automatic SSL CertificatesLast Modified: Jun 15, 2021, 5:25 pm
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.

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

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

  3. 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.
  4. 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 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).
  5. 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 file 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).
  6. 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 looing for a * 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.
  7. Debug

    You can manually see what the Ssl::admin_poll is up to by running it manually wish the SSL debug level:

    cd /usr/local/directadmin
    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.


Automatic SSL Certificates - One Certificate Per Host (SKINS)
Admin SSL (Pro-Pack)

© 2018 JBMC Software, Suite 173  3-11 Bellerose Drive, St Albert, AB  T8N 1P7  Canada.  Mon-Fri 9AM-5PM MST