HTTPS Certificate for internal use

Pablo_Alsina_2295 0
Viewed 67201

I'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)

Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.

Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y

Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?

Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.

certificate https ssl
7 Answers

You have two practical options:

  1. Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.

  2. Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.

user_33470

You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com

Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.

Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.

In short: To make the cert trusted by a workstation you'd have to either

  • change settings on the workstations (which you don't want) or
  • use an already trusted party to sign your key (which you're looking for a way around).

That's all your choices. Choose your poison.

user_134470

I would have added this as a comment but it was a bit long..

This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.

I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.

If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.

user_671430
user_73274760

Development purpose only

This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.

It launches a reverse proxy in the port 443 with a public cert that works with any *.my.local-ip.co domain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:

$ APP_URL=http://192.168.10.10:8080 docker-compose up

The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.

The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).

user_5037430
Related