Directadmin Docs

Let's Encrypt For Services

Using the free "Let's Encrypt" tool to secure Port 2222 via the Hostname

As of DA 1.50.0, we've added a new featureopen in new window that allows you to make use of Let's Encryptopen in new window, a tool offering free basic SSL certificates.

We've written the script in such a manner that you can also set up SSL for your hostname and all services in one simple command for your hostname e.g.,:

/usr/local/directadmin/scripts/letsencrypt.sh server_cert

which will also install the new cert/key/ca files in all respective global places for Apache, Dovecot, Exim, FTP, and DirectAdmin.

DirectAdmin should be protected with SSL in 1min when the command finished.

Notes:

If user connect to https on a different host, they'll first get the ssl warning (since ssl is established before the host is passed), then they'll be redirected to the correct host, where the error would not appear (assuming you've got a valid cert set up).

DirectAdmin supports HTTP Strict Transport Security (HSTS): https://www.directadmin.com/features.php?id=1776open in new window

But we recommend you to set force_hostname to a non-apache-used host, like dabox.domain.com, and not www.domain.com, as HSTS doesn't respect only port 2222 and would bleed over to Apache, changing http://www.domain.com (80) connections to use https://www.domain.com (443), even though the header was only set on port 2222.

I want a multi-domain certificate for my hostname/mailserver using Let's Encrypt

Exim and Dovecot do support multi-IP ssl certificates, but their setup can be a little bit tricky to try and maintain.

With Let's Encrypt, we can set up multi-domain certificates for the hostname, and mail domains, all in one value, to make managing SSL for mail a little simpler.

/usr/local/directadmin/scripts/letsencrypt.sh server_cert `hostname -f`,mail.domain.com,smtp.domain.com,www.domain.com,domain.com

Setting up DA (port 2222) with a commercial SSL certificate

This guide will detail the configuration of SSL certificates for the server's services, such that the SSL is installed on the hostname and used for DirectAdmin, Exim, Dovecot, and FTP.

If you already have your own certificate and key, then paste them into the following files:

  • certificate: /usr/local/directadmin/conf/cacert.pem
  • key: /usr/local/directadmin/conf/cakey.pem

Ensure that ssl and certs are enabled in directadmin.conf file with:

/usr/local/directadmin/directadmin config | egrep "^ssl=|^cacert=|^cakey="

Sample output:

ssl=1
cacert=/usr/local/directadmin/conf/cacert.pem
cakey=/usr/local/directadmin/conf/cakey.pem

But these can be changed as needed.

DirectAdmin needs to be restarted after any changes to the directadmin.conf, please follow this guide for changes.

If you also have a CA Root Certificate, this can be specified by adding:

carootcert=/usr/local/directadmin/conf/carootcert.pem

into the directadmin.conf (won't exist by default), and then by pasting the contents of the caroot cert into that file.

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: