We help IT Professionals succeed at work.

how to certify intranet servers so browser wont' freak out?

Hi, I'm using the Quarantine feature from Watchguard and this creates a Quarantine website users can log onto. But the problem is that it's an intranet server and as such doesn't have an 'official' SSL certificate. I tried to create a self-signed one etc but I keep on failing ... could someone please give me step-by-step instructions on how to create a self-signed certificate and attach it to that website so that the browsers won't throw their security warnings anymore? Thanks!
Comment
Watch Question

David FavorFractional CTO
Distinguished Expert 2019

Commented:
Keep in mind, this will likely fail in many subtle ways.

The only way this can possibly work is if all your code + database entries refer to site with no site link.

That means if http://site or https://site lives anywhere on site, then your site will be unstable, because all these links will refer to your public site, rather than local site, unless you hack up your DNS.

Suggestion: A much better approach is to just run a copy of your site called https://staging.site.com + generate an cert to cover this host too.

This way you have a real site, which will work with SSL.
David FavorFractional CTO
Distinguished Expert 2019

Commented:
If you really must run a quarantine site (not recommended), then you must.

1) Setup your /etc/hosts to change IP locally.

2) Change all site references from https://site/path-to-asset into /path-to-asset, so strip out all protocols + site links from all URLs.

3) Copy over all your cert files from original Webserver config to local config.

In other works, create a runtime environment mirroring exactly your real site.

Author

Commented:
Hi, thanks for answering but I'm not sure we're talking about the same thing, Maybe I didn't describe my problem very well.

So here's the situation: I've got an intranet website, let's call it mysite.mycorp.local

Now when my users, inside of our mycorp.local domain, try to access this site via https://mysite.mycorp.local their browsers will display a warning, telling them that the validity of the certificate can't be verified, that the site might have been compromised, etc. Which is, of course, not the case.

So what I want to know is: how can I add a valid certificate to this INTRAnet webserver? I know how to do it for INTERnet webservers. I've bought valid certificates for those. But I thought that one wouldn't need to buy certificates for intranet servers? That one could certify those oneself?
Fractional CTO
Distinguished Expert 2019
Commented:
Got it.

This is correct.

If you self sign https://mysite.mcorp.local then you're using a non-standard issuance chain, related to your Private CA.

In this case you have several choices.

1) You push a copy of your Private CA issuance chain to every client machine.

You must push again each time your issuance chain expires.

2) You can just do nothing + tell users they must accept the cert's validity first time they visit your local site.

Summary: There is nothing you can do to fix this on the server side, as this is a client issue.

All browsers include standard issuance chains, which is why cert work from various issuing authorities, like LetsEncrypt.

3) You could also create a free https://LetsEncrypt.org wildcard cert + pass the cert around between all your services.

If you go with this approach you avoid #1 + #2

Author

Commented:
Does letsencrypt work with Windows? it seems like it's UNIX-only?
David Johnson, CDSimple Geek from the '70s
Distinguished Expert 2019

Commented:
adding a self signed certificate only changes the error/warning message. A self signed certificate in its certificate chain does not have one of the browsers trusted root certificate provider list (there are way too many of these i.e. hong kong post office
If you have your own certificate authority you have to add the root certificate to all machines (easily done by gpo) and the browser on your domain will trust any certificate issued by its chain.

LetsEncrypt is simply one of the trusted root providers (in its chain) and is OS agnostic. One method of using it via powershell is
https://github.com/PKISharp/ACMESharpCore-PowerShell

from this list: https://letsencrypt.org/docs/client-options/  you can see there are many implementations of getting and renewing a domain certificate.

You cannot get a domain certificate from ANYONE for a .local domain
@David Favor
If you self sign https://mysite.mcorp.local then you're using a non-standard issuance chain, related to your Private CA. Incorrect, a self signed certificate is not issued by any CA it is issued by the machine that created it. it is self signed -- signed by the machine it is created on.
Distinguished Expert 2019

Commented:
If you use a self-signed cert, you need to publish the certificate through the AD GPO as trusted cert after reboot the workstations will trust it

If you do not have a local CA installed, you can use OpenSSL to generate a self-signed CACertificate which you would use to sign the CSR from the webserver.
Adding the OpenSSL self-signed certificate in the GPO as a trusted CA, then any certificate signed by it for the duration of its validity will be trusted by systems to which the GPO applied on your network following the loading of the updated GPo.
kevinhsiehNetwork Engineer

Commented:
It's recommended that you don't use mysite.mycorp.local, because you can't get a publicly trusted certificate for a domain that isn't public. This is why it is recommended that your internal network be something more along the lines of ad.mycorp.com, or int.mycorp.com, or even mycorp.com, so that you can get a certificate from a public CA without issue.

You can either use a FQDN that can map to a domain that you have control over, such as mysite.mycorp.com or mysite.ad.mycorp.com, or you can go through the various self-signed certificate or private CA key distribution methods referred to above.
David FavorFractional CTO
Distinguished Expert 2019

Commented:
As David Johnson said, you must use a Private CA to create certs to cover *.local hosts.

As kevinhsieh said, far better to use public hosts records, even if they resolve to 192.168.X.X local/private/nonroutable IPs.

Then cover your entire domain (all hosts) with a LetsEncrypt wildcard cert, then just propagate the wildcard cert to any host requiring coverage.