Certificate for same short domain in multiple machines

I am developing an industrial web app "My App" and I will need to deploy an instance of the app on each of the several production facilities of each of the several customers that we have.

As an example, the domains involved are:

myapp.facility1.customer1.com
myapp.facility2.customer1.com
myapp.facility3.customer1.com
myapp.facility1.customer2.com
myapp.facility2.customer2.com
myapp.facility3.customer3.com
...

I have successfully managed to get a certificate for each instances of the app. Since the app instances are not opened to the Internet, I use DNS-01 challenge.

As you notice, the domain names can be quite long to type and I would like my users to be able to easily and quickly reach the relevant app instance when connected to the network of a given production facility.

For this, I would like to buy a short domain name that is descriptive of "My App" such as myapp.com.

In the local DNS server of each production facilities, both myapp.facilityX.customerX.com and myapp.com would resolve to the IP addresses of the machine serving "My App".

The problem is that if I request a certificate for exactly myapp.com in the hundreds of instances I have, I would quickly run into the Duplicate Certificate limit of 5 per week.

So I have several questions:

  1. Can I use the workaround by requesting both myapp.com and myapp.facilityX.customerX.com to get a multi-domain certificate instead of 2 individual certificates?
  2. Can I request the certificate in a dedicated server and deploy it on all my instances?
  3. Is this even a good idea to try to do that or are there some problems that I do not realize?
2 Likes

Yes. That's a pretty normal way of handling this sort of thing.

Yes. That's another pretty normal way of handling this sort of thing. You obviously need to be mindful that you're copying your private key across multiple systems, and if one of those machines gets compromised then you'd need to update all of them with a new key/certificate. But again, a reasonably standard thing to be doing.

There are pluses and minuses to whatever way you want to go. The integration guide has a little bit of guidance. Basically just be aware of the rate limits, be aware of where your keys are, and have a plan for what you'd need to do if something goes wrong.

6 Likes

How do you plan to distribute the new certificates once the old one is about to expire?

2 Likes

There's something about this strategy that "smells" but I can't quite find the words. You want to have a local DNS entry that resolves myapp.com to the local facilities instance of the app in order to save typing, but plenty of corporate URLs are very long and are never typed, they are clicked from existing intranet resources or desktop shortcut rollouts. Up to you though, there's just something about it that doesn't seem right to me, it may be fine.

For your idea you could consider using a secrets vault such as Azure Key Vault etc and let each instance regularly update the cert from there using their own dedicated access token. When a site is no longer allowed to pull the cert, you just revoke the token and everything stops working for them. These vault/api access tokens do expire though so there's still something to maintain. This strategy removes the need for the instances to individually renew a cert for "myapp.com" and avoids the cert rate limit.

Generally sharing cert private keys (especially between organisations) is not considered good practice but obviously this is planned/controlled rather than accidental.

3 Likes

For myapp.facilityX.customerX.com, I use a dedicated BIND server in the cloud and on my instances I use lego with RFC2136 so the certificates are automatically renewed.

If your question concerns myapp.com, it is a bit premature to plan the distribution at that stage. That would assume I have chosen to go with 2 (request the certificate in a dedicated server and deploy it on all my instances) which I have not.

so it's running on a server your customer runs, so wildcard isn't an option, right?
feels like even if you add another domain to sidestap dup certificate limit it looks like it will hit 50/week cert limit per base domain limit fast.

4 Likes

I shared this feeling as well, hence my point number 3.

To give a bit more details about my use case. I would like http://myapp.com to redirect (307 Temporary Redirect) to http://myapp.facilityX.customerX.com so that my users always browse the app with the canonical FQDN. So myapp.com is merely a shortcut to the canonical FQDN.

If a user type exactly myapp.com (without http:// or https:// prefix) in the address bar of their favorite browser and if the browser always tries http://myapp.com first (as opposed to https://myapp.com) then the user will be redirected to http://myapp.facilityX.customerX.com which itself redirects to https://myapp.facilityX.customerX.com. That would work without any certificate for myapp.com.

But I am not sure all web browsers work this way, and if one tries https://myapp.com first, then I need a valid certificate to redirect to https://myapp.facilityX.customerX.com without any warning.

1 Like

The servers are located and run at the customer's facilities but we managed them ourselves. What do you mean by wildcard? For which name (*.customerX.com, *.facilityX.customerX.com, ...)?

It does look like it indeed, thank you for pointing at this.

2 Likes

What do you mean by wildcard?

I was thinking about *.facilityX.com and make customer a subdomain of it, but obviously customer1's fac1 is different thing from customer2's fac1?

myapp.com should not try to show same thing as any subdomain but redirect to right place:
someday your client will change thing on fac1 thinking it was fac2's network

3 Likes

That is correct.

Yes, this is exactly why I want to immediately redirect to canonical FQDN.

1 Like

well that could stay in http not needing certificate (unless they start to do https only or from central host

3 Likes

I think browsers must all default to http. I have not checked but there are good reason for doing so and I do not think it is going to change anytime soon:

So I probably do not need any certificate at all.

For the record, on my Netgear R7000 router, it is mentioned at the back of it:

ROUTER LOGIN
http://www.routerlogin.net
user admin: admin
password: password

Neatgear owns routerlogin.net.

When inside the network provided by the router, http://www.routerlogin.net serves the router admin web app. https://www.routerlogin.net also serves the same app but the certificate is self-signed so you are presented with a warning screen.

When outside the network provided by the router, http://www.routerlogin.net redirect to https://www.routerlogin.net which serves some information.

But how if those instances aren't connected to the internet?

2 Likes

I did not say there were not connected to the Internet, I said there are not opened to the Internet. In other words the firewalls of the facilities block incoming traffic to the web app, like the default configuration of any home router.

myapp.com was an example.

I tried myapp.app but this strategy does not work with .app gTLD because this top-level domain is included on the HSTS preload list, making HTTPS required on all connections to .app websites.

Aah ok, I misunderstood then. My bad.

2 Likes

How would your server know which destination to redirect to?

On my mobile phone I have https-ONLY mode set in Chrome today.
Set Up HTTPS by Default in Your Browser | Electronic Frontier Foundation.

There is also Chrome's https-FIRST. Here are more recent articles about this.

3 Likes

Another option is to have a public site that redirects with custom short subdomains, such as abc123.myapp.com could redirect to the the long name of the internal site. You could obviously decide on more useful names.

Personally I think you could just leave the sites with long names. They will link to them, not type them. I realize though that you're probably trying to build a common brand.

2 Likes

Because the server is located in the production facility so if it is located in facility1 of customer2, then it will serve the app with the canonical FQDN myapp.facility1.customer2.com. The same server would always redirect http://myapp.com to http://myapp.facility1.customer2.com.

That is interesting, then I guess I cannot get away without providing valid certificates then.

2 Likes