Questions about Let's Encrypt wildcards

First, I plan to use a cheap RapidSSL certificate or something similar for domain.tld & www.domain.tld, and Let’s Encrypt for everything else. I’ve never used LE’s wildcard feature and I see lots of potential for mistakes. Aside from running LE’s script in dry run mode first, does anybody have suggestions or caveats about mixing certificates this way?

Second, for the purposes of using a LE wildcard certificate, is an Apache config necessary and do I need a wildcard subdomain created in Siteworx? Or will a wildcard A record or CNAME for *.domain.tld be enough? The former makes the most sense, where as the latter seems like any directory can be translated into a subdomain, which sounds like trouble to me.

I’m interested in best practices, pros & cons, etc. Thanks!

Hi Sysnop

We use LE on our servers, and have since it was introduced. Works extremely well and so far, no issues

The best way to complete it, is to create a siteworx account for FQDN of server, create LE SSL for all records, then goto nodeworx, server, SSL, update server certificates, select domain and choose the siteworx account of FQDN of server, select all services and restart all services and save.

this then sets the server SSL for services to use the same a FQDN siteworx LE SSL and the siteworx account autogenerates the LE SSL prior to expiry

You can use a paid SSL and install in the normal way, and yes, you would use wildcard *.mydomain.url but LE SSL allows for sub-subdomain, so it could be eg where as wildcard certs are limited to 1 subdomain eg mail.mydomain.url

I hope that helps a little

Many thanks and stay safe


Thanks John. This part is clear and is how I usually cover the server hostname with Let’s Encrypt.

My main question is more about the pull-down selector on the LE plugin page in Siteworx. Getting ‘*.domain.tld’ to show up as an option for a wildcard certificate is apparently done a couple different ways. Either 1) create a subdomain called *.domain.tld in Siteworx or 2) create the wildcard DNS record only. I’m questioning which is preferred for a certificate. But the more I read about it the more apparent it becomes that I need a vhosts entry in addition to a DNS record for use with a SSL certificate. It would help if someone could confirm this is right.

Hi Sysnop

Many thanks

I think you maybe getting slightly confused over the vhost file if setting up LE SSL outside of a siteworx account

You can manually create and cron a LE SSL to be renewed without a vhost file - just needs correct DNS and a text file - no need for a vhost file


you can create a siteworx account for FQDN of server (vhost file created), use siteworx account to create LE SSL and cover all DNS records (alternate name) and set nodeworx SSL to use domain (select FQDN domain you created) and leave well alone moving forward.

The latter autorenews without interactions and is easier to create

Ahh sorry now I understand sorry

You cannot have a LE SSL wildcard cert as yet. IW have it on roadmap I believe but also seem to remember reading that LE SSL wildcards were changed on how to use them/create them.

So the answer is to create FQDN siteworx account and DNS records for any additional subdomains you may use, which makes them appear in the alternate name and can be included for LE SSL

I hope I have understood correctly and I have just tried using create *.domain.url as DNS A and sub domain, both failed to appear in the alternate name drop down box

Many thanks


This is fine, but until wildcards are a supported option the popup text suggesting otherwise should be more clear.

So the answer is to create FQDN siteworx account and DNS records for any additional subdomains you may use, which makes them appear in the alternate name and can be included for LE SSL

I’m familiar with this but I’ve got a problem with the server SSL. Let’s Encrypt fails when I add the server hostname to the list of alternative names. When the server hostname is omitted LE creates a successful dry run for all other names.

server.domain.tld - fails
ftp.domain.tld - works
mail.domain.tld - works
sub1.domain.tld - works
sub2.domain.tld - works

The problem is likely because the server has a self-signed certificate (installed in Nodeworx) that needs to be removed. What files do I need to remove or change in order to remove the self-signed certificate and start clean?

Hi Sysnop

I am sorry but is there a DNS entry for server.domain.tld (where the domain.tld DNS is controlled - apologies if sounds a strange question but the domain.tld DNS maybe on a different server perhaps).

If not, this is the failure for LE SSL to create record - infact, what error is shown in LE SSL logs for domain.tld showing for server.domain.tld entry - DNS entry not found would mean no DNS record exists or can be found and usually points to record not setup on correct DNS server - or not listed perhaps at secondary DNS servers

You can delete the SSL used in nodeworx services by editing the SSL used on service and then delete all 3 boxes (private key, ssl cert and chain) and click save. Should work but have not tried it myself sorry

Using LE SSL from a domain should work and delete the self signed, replacing with LE SSL from domain chosen

I hope that helps a little and hope you keep safe

Many thanks


Thanks John! Hope you’re doing well also.

There’s no way I can see to remove a self-signed server certificate in Nodeworx.

Using LE SSL from a domain should work and delete the self signed, replacing with LE SSL from domain chosen

This does work to replace the self-signed cert but it’s no help in my case without the server hostname as an alternate.

Yeah, this is strange. I’ve never had this tough a time with Let’s Encrypt. DNS records are in order, the hosts file and all network configs look ok. It would be nice to use LE for the server cert but when I think it over it’s not crucial and a self-signed cert will do for now. What matters is that subdomains are working.

You might be onto something about a different network because something about the server hostname doesn’t seem to be resolving.

Here’s a typical log entry when the server hostname is processed by LE:

AuthorizationError: Some challenges have failed.
The following errors were reported by the server:
Domain: server.domain.tld
Type: unauthorized
Detail: Invalid response from http://server.domain.tld/.well-known/acme-challenge/weECDf_dCzcPRzH6ORAOQaED36Og_a_YF5RLIbfKMxM [IPv6 address here]: “<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<title>404 Not Found</title>
<h1>Not Found</h1>
To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.

After searching some of this verbage, one person at the LE support site had IPv6 issues while another person’s problem was IPv4 not resolving. I tried eliminating IPv6 networking and removed all AAAA records with no success. Other than that, I’m stumped.

Hi Sysnop

Many thanks.

UK is in a little mess at moment I think, almost total country shutdown now… I believe I am classed as a key worker as we do support manufacturing companies (some make parts for food industries, mod, petrochemical etc…) but always try to work remotely unless an onsite server goes down…

Still cannot buy toilet paper, no idea why and without making light of a serious outbreak, on a vehicle forum I belong to, one poster posted - toilet roll shortage is because when 1 person sneezes, another 10 people sh!t themselves (I am very sorry to anyone that that may offend or upset sorry - it is a means of coping with a very bad situation we are facing)

Hope USA/you are fairing better

If you want to PM me your correct server.domain.tld and I will check if all DNS is correct from here and if so, I would open a support ticket with IW as Bertie has an mail server issue which turned out to be DNS related (however, I think from memory he had changed his FQDN hostname on server)

One last thought, you could try to fully stop IPv6 on your server NIC and restart server or network to see if it then works (/etc/sysconfig/network-scripts and edit your correct ifcfg-eth and set IPV6INIT=NO)

Its just a thought as it is a strange one and no notifications from LE over any maintenance or outages received

Many thanks


This is the funniest thing I’ve heard in a long time! The TP situation is a problem across the US too. But it’s not a mystery here – full-of-sh!te politicians are hoarding it.

I’ll take you up on your offer to inspect my DNS. But first, just for grins, I’m going to try a new hostname even if it doesn’t make sense, disable IPv6 and let new records resolve a while. I set a low TTL and will try again in a few hours. I’ll contact you tonight or tomorrow.

Thanks again!

Hey John,

My server hostname validated with Let’s Encrypt today and the certificate is working. I ended up using the Siteworx method you’ve mentioned many times before, including this discussion betwen you and Nico that was extra helpful:

I’d rather create a server cert the old way without the extra Siteworx account, i.e., A & AAAA records in one zone. Plus I had to change the IP from dedicated to shared in order for an IP to be available to Siteworx. But as long as this method is viable and plays nice with SMTP & IMAP, I should be good to go.

I sure would like to know what prevented the hostname from validating by LE certbot that worked well for so long. I’m tempted to think it’s because of a change in their code. Coincidence or not, this problem seems to have started shortly after LE announced recently (February?) that certs needed to be re-issued because of a security flaw of some kind. It was all up hill after that, but now I’m hoping it’s solved and in the rearview.

Thanks once again!