The guys at ISPConfig do good work – although it can sometimes get in the way of my own server configuration, the vast majority of the time it saves a huge amount of effort on what would otherwise be mundane and routine tasks.

With FOSS solutions like this though, “must-have” features don’t always come quickly – CPanel implemented Let’s Encrypt functionality very early on, but ISPConfig users had to wait 6 months (which is pretty fast considering the circumstances).

I needed a solution immediately though, which is why I rolled this (reasonably awful) automation to integrate.

The solution has worked well enough for the past 12 months or so (although implementation on slave servers wasn’t easy or pretty), but I figured it was time to upgrade to ISPConfig 3.1 – with built-in Let’s Encrypt support.

It’s almost always best to stick with the native solution rather than a third party one (particularly when the third party one is developed by a time-poor hacker), and that rule largely applies here.

ISPConfig Native Implementation: Pros

• Zero config outside ISPConfig’s interface (with one exception – see below)
• Selective SSL – not all sites need to download a cert (although it might be a good idea for SSL to be the default in the future)
• No issues when updating ISPConfig in the future
• By far the easiest, safest way for multi-server slaves
• Works with the official Certbot software from EFF (mine uses Dehydrated)

Cons

• Doesn’t cover control panel certificate
• Doesn’t bundle subdomains as a SAN certificate
• Doesn’t cover aliases or subdomains – only sites

The first issue is addressed easily enough – you need to create a site for the domain used by the control panel (if it doesn’t already exist), mark it for SSL with Let’s Encrypt and then symlink your ISPConfig interface certificates to the freshly pressed certs used by the site. Admittedly, this usually involves making a whole extra vhost where it isn’t technically necessary, but if you’re using a control panel to manage your hosting anyway, performance probably isn’t your primary concern.

The files in question are:

#ISPConfig interface certificate files (symlink to your site certs)
/usr/local/ispconfig/interface/ssl/ispserver.crt
/usr/local/ispconfig/interface/ssl/ispserver.key

#Site certificate files - location depends on your CP domain:
/var/www/panelurl.example.com/ssl/panelurl.example.com-le.crt
/var/www/panelurl.example.com/ssl/panelurl.example.com-le.key

Just link your site’s crt file to ISPConfig’s interface crt and the key to the key. Restart your webserver and you’re laughing.

The second issue has no native solution (yet?), but why is it a potential problem in the first place?

Let’s Encrypt implements “rate limiting“, a ceiling on specific kinds of requests within specific time-frames.

Since coming out of beta, Let’s Encrypt have actually made these limits more generous, and unless you have a particularly crowded server or collection of subdomains, you’re probably unlikely to come up against a ceiling.

Pretty much the one advantage of my solution was the bundling of subdomains and aliases into a single SAN. For some, this is unacceptable anyway – SAN certificates are too broad and there is some comfort in one-cert, one-site.

But for up to 100 subdomains on a single server, my third-party solution will pull down a single SAN cert and push it to each site.

I strongly recommend against using my solution – find a way to work with the native system – but if you really need SAN for some reason I will leave the repo up on GitHub. There are some slave-only changes that need to be pushed to the public repository, and I’ll do that soon.