Let's Encrypt Issue

I'm trying to get a letsencrypt certificate for a website through ISPConfig. It's failing and what's interesting is that in the email I get to report the error, it includes an additional domain.

That is, the reported command line to LE has something along the lines of this: "-domains example1.com -domains www.example1.com -domains example2.com -domains www.example2.com". Where I'm trying to get the certificate for "example1.com" - so that's right - but not for "example2.com".

It's, for some reason, picking up this other domain as well. But the thing is that though this additional domain is a domain name that we have used before, it's no longer active. The website is gone.

I did hold onto the domain name in the "domains" page of "clients", as we do still own the domain name itself, even though it's not in current use. But I removed the website and there's no DNS entries for it. Yet when I tried to delete this domain name from the domain list - to try to clear it out of ISPConfig, so that it couldn't be wrongly picked up for the LE certificate - then it says that it cannot be deleted, as it's a web domain. But it isn't. The website is not there. There is no entry for it in the "sites" page.

There appears to be some kind of "ghost in the machine" of a domain name that was in former use, but not anymore, that I can't seem to clear out. And it's getting in the way of the LE certificate process as, for some weird reason, it's being included in the domains sent to LE. But as there really is no such website and no DNS entries for it then of course LE's servers are rightly denying it - their servers must be trying to access "example2.com" and not getting any response, fail the whole operation. Even though I don't want "example2.com" to be even involved in this.

Where is ISPConfig getting the domains and such from in the database? I could always go into PHPMyAdmin and fix things, if I knew where the problem could even be.

 

Nope, there is no alias nor subdomain in the sites module. Like, none at all. No-one's making use of that feature.

I might have used this "example2.com" domain, though, whilst testing things out at some point. It's basically a "spare domain" that we've got that I use for testing purposes. So, it has been used previously and I might even, to test out the alias feature, have used it there.

But, right now, there is no trace of it in the aliases, subdomains or websites at all.

Where else could this domain be hiding to get picked up by LE?

As a testing domain, I might also have tried out the LE features using it, but then cancelled it - because that's what I use this "spare" domain for. So, at some point, I've tested most features using it, because it's a domain that doesn't matter.

(Well, it was originally purchased with a view to making a website for a side business we were looking into. That, as yet, hasn't happened. So, while it sits around, I make use of it for testing purposes.)

If it's not in the database anywhere, could it be being remembered in a file? Does LE keep track of domains and is, for whatever reason, oddly misrembering this one? As there is no such site - not even any DNS for it - then, yes, if LE tries it then it's guaranteed to fail. The problem is that it's blocking other sites from getting their LE certificates.

 

Look in directory /etc/letsencrypt. It has subdirectories archive, live, renewal. Check if there is file for that problem domain in those subdirectories. If not, grep for the domain name, maybe it is included in some other domain.

 

I did take a cursory glance over the filenames in those directories. I didn't see the domain name in any filenames there.

Though, there are a couple of directories that are filled with ".pem" files that have sequential filenames. Due to that naming scheme, I can't immediately see what domains they're for. But, as SSL certificates, they would have - somewhere within them - the domain names.

I could, I guess, go through them and run "openssl" on each one to read what domains they cover but I haven't done that yet, as it'll be a tedious job to do manually. But, hey, if that's the way to find and fix the problem, I'll give it a go later.

And, yes, of course, grep for it. Thanks for stating the obvious there, as sometimes one's brain can forget the obvious basic steps.

I don't have access to the servers right now to do anything. But I'll investigate further when I get the chance.

(Because now that Google has switched to the "Not Secure" message in the address bar, I have a client who, prior to this, said nothing, now phoning me in a panic at the cost of SSL certificates. I mean, Google did give two years advance warning on this, but he apparently missed it all.

Anyway, I want to be able to say to him "don't panic, just turn on LE for the domain" confidently, but at the moment it has to be "I'm working on it". I do have, by the way, a bunch of domains with LE that are renewing just fine - so I know the overall process works, but there are still these small glitches here and there preventing the smooth operation I would like.)

 

I tried turning off SSL for the website - LE itself is already disabled because it won't stay on if the process of getting an LE certificate fails - and then turning it back on. Then turning LE back on.

But no dice. The "example2.com" domain that shouldn't really be there at all is still being reported back to me in the error email (which contains the command line it's attempting to run, including the extra domain).

I have no idea how it's picking this domain up. But it is. And until I can shift it, then this website can't grab its LE certificate.

 

I checked through each of the cluster's databases one-by-one and, yes, the domain was sitting in the web_domain table of one of them. But not the others. Somehow things had gotten out of sync between them. I manually corrected the disparity - that is, deleted the domain from that one table which had it wrong - and then things started working again.

Thanks all.