0

I have two servers; one is the 'official' example.com server that hosts my public website as well as mail servers (bluehost.com). The second is my private LAN server which hosts my point of sale application and general 'manager' application.

The example.com server has a wildcard SSL purchased and applied. I wish to use this certificate for all apps hosted on the private LAN server since it's a trusted certificate and it all apps mentioned are under the purview of the same company. I've read that this is simply a matter of copying the private and public key/cert files onto my server and configuring nginx to use them. I've done this but there is the issue that my current URL scheme (http://pos/ and http://manager/) won't end up matching the domain of the wildcard certificate.

The immediate solution would be to force all nginx LAN servers to use the longer URLs (like http://pos.example.com), however I'd like to avoid having to do that. Is there an elegant solution for this problem? The actual registered domain name takes a long time to type on mobile devices and it would just add a source of confusion for my employees using the pos/manager apps.

Would changing my LAN's connection-specific suffix to example.com help in any way?

2
  • Why do your employees need to type in the long names? Just redirect from the short name to the long name. Nov 22, 2015 at 19:18
  • You should already be using fully qualified domain names. And your users should be using bookmarks/shortcuts, not typing in URLs. Nov 22, 2015 at 20:31

2 Answers 2

0

Unfortunately if you do this your employees will need to type the fully qualified domain name as you have seen.

It is possible to automatically redirect from http://pos to https://pos.example.com but not from https://pos as the certificate negotiation happens before the redirect. The alternate is to add bookmarks and the like.

It is not possible to do any system set up to auto append the domain name to the browser request (though it is possible to resolve the shorter name to the full name but that will still leave the cert issue).

You could use an internal self-signed cert instead and in my experience this is how most companies handle this. As you would be creating the cert it would be free and you could add the short domain as well as the fully qualified one. This would however mean you have to add the cert issuer to all your internal browsers which, depending on your set up may not be trivial. Especially when mobiles are involved. Ultimately it might be easier just to get people used to the fully qualified domain name.

And I would also agree that best practice would be for externally visible domain not to be used internally. Can cause issues.

2
  • On your last point; what sort of issues? Aside from the obvious (oops I made a subdomain "pos" on both the external site and internal LAN site). Nov 22, 2015 at 20:55
  • Well, as well as where to manage the DNS (publicly or not) and how widely to share that private key, things like this can cause unexpected issues: serverfault.com/questions/665234/… Nov 22, 2015 at 21:03
0

Just one of possible solutions. Configure things so that internal devices connect to the internal services (pos, manager) via a public IP (not 192.168.x.x) and a public name (https://pos.example.com). Of course secure the public IP to be only available from your sites, and not from the Internet.

On your internal nginx also add permanent redirections (HTTP 301) from http://pos (internal IP) to https://pos.example.com (public IP).

The disadvantage of this solution is that the traffic goes one hop more than absolutely needed, and you need to be careful about public IP security.

The advantage is that you don't need to change anything on user devices (no manual certificate trusts).

2
  • Using .local is a bad practice, not a good practice. Nov 22, 2015 at 20:31
  • @MichaelHampton So there goes my golden rule. Thanks for the info :)
    – kubanczyk
    Nov 23, 2015 at 8:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .