Subdomains at two hosting providers

[jcflack]

Hello,

Here at example.com, we have had a several-year relationship with hosting provider A that hosts several services for us, on several foo.example.com 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 www.example.com now points to provider B. All other foo.example.com records, and example.com 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 example.com:80 and :443 over to www.example.com 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 www.example.com - 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 www.example.com unless we also move the A record for example.com 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 example.com domain from your registrar here for us to generate this for you.

(where "both instances of your example.com domain" is their weird way of saying "both www.example.com and example.com", 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 example.com over to quux.example.com, just so I can point example.com 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 example.com doesn't point to us any more"?

Somebody please tell me there's a solution.

[_az]

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 example.com and www.example.com.

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 example.com. 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 …

[jcflack]

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 exmpl437.com 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 example.com … I really want them to be www.example.com, and know they are www.example.com, and nothing else.

[_az]

@jcflack

I never said anything to provider B about wanting them to set up anything on example.com

Well, it seems like someone/something did. Otherwise, why would their system even try for example.com 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 www.domain.com.

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.

[rg305]

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 “xyz123.domain.com” they would not automatically include “domain.com” 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 -]

[jcflack]

[- 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 example.com A record over to provider B, which seems to be the only way B can make things work.

[jcflack]

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.