HTTPS Certificate for internal use

Question

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)

Answer 1

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.

Answer 2

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.

Answer 3

I did the following, which worked nicely for me:

I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)

I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".

I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.

Answer 4

I had a similar requirement, have our companys browsers trust our internal websites.

I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.

Heres the writeup for this,

https://medium.com/@mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af

Answer 5

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.

Answer 6

i think the answer is NO.

out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.

you can only get a verified certificate for a globally unique domain.

so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.

also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.

(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)