Let's Encrypt For Services
Using the free "Let's Encrypt" tool to secure Port 2222 via the Hostname
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.,:
./letsencrypt.sh request_single $(hostname -f) 4096
which will also install the new cert/key/ca files in all respective global places for Apache, Dovecot, Exim, FTP, and DirectAdmin.
NOTE The hostname value, e.g., your.hostname.com must match the "servername" value set in the
directadmin.conf, or it will not be in hostname mode, but User domain mode instead.
DirectAdmin should be protected with SSL in 1min when the command finished.
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=1776
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.
To do this, we use the
letsencrypt.sh script normally, but we would manually create the
ca.san_config file loaded with the values we want to use.
However, with Let's Encrypt 1.0.4+, we can specify all values on the command line instead, like this:
./letsencrypt.sh request `hostname`,mail.domain.com,smtp.domain.com,www.domain.com,domain.com 4096
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:
Ensure that ssl and certs are enabled in
directadmin.conf file with:
/usr/local/directadmin/directadmin config | egrep "^ssl=|^cacert=|^cakey="
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:
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
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 (
Note that DA supports SNI for per-domain Dovecot SSL certificates.
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 220.127.116.11.
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").
For any Reseller (or just admin) that needs to have access to it in order to assign to Users, it needs to be in:
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.
- The template (important part) is where we manually set it to use the other certificate.
cp ../ips_virtual_host.conf .
Find this line (the SSL VH on 443):
And immediately above it, add the code:
Which controls the automatic adding of VirtualHosts to the following file (don't edit this file directly)
These within this file are the first VHs for the IP, and thus control which certificate is used.
- You might need to do the same thing for the
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.
Exim + Dovecot
Note that the exim.cert contains BOTH the cert and the ca, in that order.
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:
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
echo "action=syscheck" >> /usr/local/directadmindata/task.queue.cb
/usr/local/directadmin/dataskq d14 --custombuild
If you get output:
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.