Subdomains at two hosting providers


Here at, we have had a several-year relationship with hosting provider A that hosts several services for us, on several subdomains. Provider A started using Let’s Encrypt a few years ago, works great, certs magically appear for all our subdomains, we couldn’t be happier.

Fast forward to now: we’ve added a new relationship with hosting provider B, just for their spiffy website building tech, only to use for a new website. The A record for now points to provider B. All other records, and itself, still point to provider A. (For the convenience of web visitors who leave off the www., we do have redirects on provider A from and :443 over to so they see the web site on B.)

Here’s the snag: provider B also uses Let’s Encrypt. We would like them to generate a cert for - for only that one name, the only one we have pointed to them. Everything else in our namespace still points to provider A and already has perfectly good certs installed there.

Provider B insists that they can’t possibly generate a Let’s Encrypt cert for unless we also move the A record for to point to provider B (thus breaking all our services on that hostname at provider A!).

Is that really something Let’s Encrypt can’t do? This is the actual reply from provider B’s tech support:

we do use ‘lets encrypt’ however our service is dynamic and software based, and as such is directly integrated into their API … Based on our configuration with Lets Encrypt you would as Cameron mentioned, need to point both instances of your domain from your registrar here for us to generate this for you.

(where “both instances of your domain” is their weird way of saying “both and”, as if they aren’t able to see them as distinct names).

It seems more likely to me that Let’s Encrypt could certainly do that, but these guys at provider B need help seeing how. I mean, is it really that unheard of to direct just one subdomain A record off to another provider to use one spiffy service that provider offers?

And anyway, suppose I laboriously move all our existing provider A services on over to, just so I can point over to provider B the way they say is necessary for them to generate a cert. Is the next shoe to drop when provider A says “hey, we can’t renew the certs for any of your subdomains here, because doesn’t point to us any more”?

Somebody please tell me there’s a solution. :slight_smile:

1 Like

There’s no such restriction with Let’s Encrypt.

Where there might be a restriction is in Provider B’s integration of Let’s Encrypt. Their system might always assume that it is authoritative for the base domain, and so it always tries to order a certificate for both and

It’s not an uncommon problem to encounter in environments that have virtualhosting.

In situations like these, the “original sin” is setting up both services at Provider A and Provider B with the base domain set to All the problems are a consequence of that.

Of course, Provider B’s system could be more flexible in this case, but evidently it isn’t …

1 Like

So, if their system does always assume it has to order both certs, how hard can it be to fix that? (I haven’t asked what client they’re using, certbot or whatever.)

I’m puzzled by your “original sin” comment; is it suggesting that whenever a company forms a relationship with another provider to offer another service, it should register some rando new domain to use with the new provider? I often enough see that done by other companies, and it always strikes me as lame: (1) it confuses visitors (especially security-conscious ones), (2) it exposes what ought to be internal details of how services are divvied up, and (3) it just basically abandons the whole idea of having a single coherently managed recognizable namespace.

I never said anything to provider B about wanting them to set up anything on … I really want them to be, and know they are, and nothing else.

Well, it seems like someone/something did. Otherwise, why would their system even try for in the first place?

It's hard to speak in generic terms, but I'll give you an example.

In shared hosting, people often sign up for hosting accounts with non-existent domains, or domains that are otherwise delegated elsewhere. They do this because at the time, they're unsure of how things are going to shake out in the end. Then they add their actual domain as an alias.

Some problems can occur with certificate coverage as a result, not dissimilar to the one you're having.

In these cases, there is a solution: you ask the web host to change the primary domain of your hosting account to something that makes sense.

For example, you could ask Provider B to rename your service's primary domain to

I don't know if this is going to be relevant with whatever decisions Provider B has made with the way they issue certificates, but it's worth a shot.

1 Like

The “problem” may be created when the provider “automatically combines” www with the base domain.
[which may fit 99.9%+ of their requests]

I’m pretty sure if you asked for “” they would not automatically include “” in that request.

What I can’t understand is how they can’t “override” that default for your particular case.

…As if they aren’t really too savvy on how it works “under the hood”.
[and my mind starts to drift]
“The guy that handled that… who knows how to do that is… um… no longer with this company.”
[- time for a NEW company -]

1 Like

[- time for a NEW company -]

I totally hear you, rg305. The thing is, I wasn’t closely involved in the choice of provider B, and another member of our organization already put beaucoup hours in building a site there, so I might feel a certain satisfaction saying “just eighty-six provider B” but the karma wouldn’t all be positive.

As it turns out, a little more experimenting shows that what B’s system is doing isn’t as bad as I first thought. It’s worse. I had an extra domain b.c to play with, so said “let’s delegate a.b.c and www.a.b.c over to provider B and see what happens.” Presumably, those would be the “www version” and “non-www version” of each other, and with both A records pointing there, B should be happy, right?

In fact, B’s server ends up responding to these four requests as follows:

HEAD https://www.a.b.c/ HTTP/1.1
Host: www.a.b.c

HTTP/1.1 404 Not Found

HEAD https://a.b.c/ HTTP/1.1
Host: a.b.c

HTTP/1.1 404 Not Found

HEAD https://www.b.c/ HTTP/1.1
Host: www.b.c

HTTP/1.1 302 Found
Location: https://b.c/

HEAD https://b.c/ HTTP/1.1
Host: b.c

HTTP/1.1 200 OK

So, it doesn’t respond at all to either of the expected names delegated to it, and it has decided it should respond as b.c which it has no business doing, and also www.b.c which is also wrong.

So their management UI is just taking whatever names the customer enters and ignoring everything back to the rightmost two domain components, and then making another version with www tacked on to the left of that.

That’s a bigger problem than just not generating our cert. But at least it explains why it’s not generating our cert.

Off to find out whether provider A has things together enough to keep renewing our certs there even if I point the A record over to provider B, which seems to be the only way B can make things work.


The end of the story so far: provider A indeed saves the day by having no problem generating subdomain certs independently of where the parent A record points, so we were able after all to satisfy provider B’s bogus requirement that the parent record point at them.

It wasn’t anything like painless, and involved additional cascading shuffles of other MX/CNAME/A records to keep other stuff from breaking, and still some client configuration updates were needed too. But at least there was a workaround, thanks to provider A being able to handle that situation where B isn’t.

Provider A uses cPanel, which turns out to have quite a rich set of tools for managing SSL certs, including per-hostname enabling or disabling of AutoSSL renewals.

Provider B has been pointed at this thread in case their developers want to improve matters down the road, but didn’t sound like they would get to it soon.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.