Directadmin Docs

Automatic TLS Certificate For Server Hostname

Using automatic certificates for server hostname

DirectAdmin can automatically issue (and renew) a certificate for server hostname using the Let's Encryptopen in new window or ZeroSSLopen in new window certificate providers. Certificates are acquired using the standardized ACME protocol.

A server hostname certificate is used for TLS connections that use server hostname (not a domain owned by one of the sever users) by the following components:

  • DirectAdmin web interface (port 2222).
  • Apache, Nginx, LiteSpeed, or OpenLiteSpeed web servers (port 443).
  • Exim and Dovecot mail servers.
  • Pure-FTPd or ProFTPD FTP servers.

This feature can be controlled by server administrator accounts in the Server Manager -> Server TLS Certificate page.

Server TLS Certificate Status

If automatic certificates are not enabled on the server, a Turn On button will be visible. This button provides an easy way to enable the default automatic certificate configuration and issue a server certificate immediately.

Advanced automatic certificate configuration options are available in the ACME Settings page.

A certificate status page can also be used to enable TLS for the DirectAdmin web interface.

When a new certificate is acquired, it will be automatically copied for web, email, and FTP services.

If an automatic certificate issue or renew operation fails, a system message will be sent to all administrator accounts on the server with more details about the failure.

Notes:

DirectAdmin supports HTTP Strict Transport Security (HSTS).

Adding more domains to the server certificate

A server certificate can be configured to include more domains in addition to the server hostname.

Additional domains can be configured in the Server Manager -> Server TLS Certificate -> ACME Settings page.

ACME Settings, Additional Domains section

Using external (commercial) TLS certificate

Configuring an already acquired certificate as a server certificate can be done in the Server Manager -> Server TLS Certificate -> Change Certificate page.

Change Certificate

SSL Certificates with Exim

By default, the /etc/exim.conf will use the cert/key files as controlled by the exim.conf's options:

tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key

Intermediate Certificates

If you have a CA Root certificate (ca bundle, chain, etcetera), you'll add the contents of your CA into the exim.cert, after your actual certificate. Make sure to keep backups of all files in case errors are made.

Dovecot and ProFTPD should also read it correctly, so Dovecot no longer needs the ssl_ca option.

So for both cases, there is no need to make any changes to either the exim.conf or dovecot.conf (/etc/dovecot/conf/ssl.conf).

Note that DA supports SNI for per-domain Dovecot SSL certificatesopen in new window.

I want a 2nd shared certificate on a 2nd shared IP installed for Apache

There might be some cases where you'd want 2 IPs, both with their own shared certificates (e.g., each has its own wildcard certificate, or you might have 2 different hosting companies). This can be done for Apache, but requires a few manual changes.

These instructions reference the 2nd IP, which will be the IP we're manually going to share among many Resellers (contrary to the default behavior DA allows).

We'll call it 1.2.3.4.

  1. The 2nd IP must be "shared" so that multiple Users can use it. Set this at the Reseller Level -> IP manager for whichever account controls the IP (e.g., "admin").

  2. For any Reseller (or just admin) that needs to have access to it in order to assign to Users, it needs to be in:
    /usr/local/directadmin/data/users/resellername/ip.list

For example, replace resellername with admin or the name of the Reseller, etc.

It's only really an issue if you have multiple Resellers/Admins.

  1. The template (important part) is where we manually set it to use the other certificate.
cd /usr/local/directadmin/data/templates/custom
cp ../ips_virtual_host.conf .

Edit the custom/ips_virtual_host.conf file.

Find this line (the SSL VH on 443):

<VirtualHost |IP|:|PORT_443|>

And immediately above it, add the code:

|*if IP="1.2.3.4"|
|?CERT=/etc/httpd/conf/ssl.crt/subdomain.cert|
|?KEY=/etc/httpd/conf/ssl.key/subdomain.key|
|?CAROOT=/etc/httpd/conf/ssl.crt/subdomain.cacert|
|*endif|

Which controls the automatic adding of VirtualHosts to the following file (don't edit this file directly) /etc/httpd/conf/ips.conf.

These within this file are the first VHs for the IP, and thus control which certificate is used.

  1. You might need to do the same thing for the virtual_host2_secure.conf and virtual_host2_secure_sub.conf, but in theory, this shouldn't be needed (though this might be a good idea, as the VH's cert wouldn't match the 2nd IP cert).

SSL Certificate Locations

General information for default certificate locations for various services. The order will be cert,key, ca/chain, combined (cert+ca) and their related directadmin.conf settings, where applicable.

Apache/LiteSpeed

apachecert=/etc/httpd/conf/ssl.crt/server.crt

apachekey=/etc/httpd/conf/ssl.key/server.key

apacheca=/etc/httpd/conf/ssl.crt/server.ca

OpenLiteSpeed

openlitespeed_cert=/usr/local/lsws/ssl.crt/server.crt

openlitespeed_key=/usr/local/lsws/ssl.key/server.key

openlitespeed_ca=/usr/local/lsws/ssl.crt/server.ca

Nginx

nginx_cert=/etc/nginx/ssl.crt/server.crt

nginx_key=/etc/nginx/ssl.key/server.key

nginx_ca=/etc/nginx/ssl.crt/server.ca

/etc/nginx/ssl.crt/server.crt.combined

Exim + Dovecot

/etc/exim.cert

/etc/exim.key

Note that the exim.cert contains BOTH the cert and the ca, in that order.

User Domain

/usr/local/directadmin/data/users/USER/domains/DOMAIN.COM.cert

/usr/local/directadmin/data/users/USER/domains/DOMAIN.COM.key

/usr/local/directadmin/data/users/USER/domains/DOMAIN.COM.ca

/usr/local/directadmin/data/users/USER/domains/DOMAIN.COM.combined

DirectAdmin may automatically create the .combined version of the cert, when needed by various servers.

If you see one on disk beside the cert, put the cert + ca into the combined file, e.g.,

cat /etc/nginx/ssl.crt/server.crt /etc/nginx/ssl.crt/server.ca > /etc/nginx/ssl.crt/server.crt.combined

SSL warning about older SHA1 certificates

Some older certificates may have this info:

Signature Algorithm: sha1WithRSAEncryption

Newer versions of openssl 1.1 no longer support them, so if they're loaded into apache, it will fail to start.

Internal default option has been added: ssl_allow_signed_sha1=0

This will force DirectAdmin to do a check at update time to look for these certificates and report back if any are found.

These certificates will not be allowed to be pasted in, nor imported via backup when ssl_allow_signed_sha1=0 is set. You can override the setting and allow them by typing:

/usr/local/directadmin/directadmin set ssl_allow_signed_sha1 1
service directadmin restart

DirectAdmin won't be removing SHA1 certificates. It's up to you to clear them out

Ensuring you've rid yourself of SHA1 certificates

Run:

echo "action=syscheck" >> /usr/local/directadmindata/task.queue.cb 
/usr/local/directadmin/dataskq d14 --custombuild

If you get output:

Ssl::found_sha1_certificates: JSON

with JSON below it, those will be your sha1 certifiates. You'll also get another Message System notice:

Subject: A system issue requires your attention

If there's no JSON and Message System notices, that means you've cleared all SHA1 certificates.

Last Updated: