HTTPS encryption

Are there still have SSL encryption between the web browser and the web server?

Yes. If this is a cert from your internal PKI you can issue with the FQDN (intranet.abc.com and the single label name intranet as SAN's). If it is a certificate from a public CA, you cannot have the single label name, which means you will need to click through/ignore any errors the browser presents for not trusting the certificate. The Internet has been around long enough that people should be used to the idea of typing FQDN's by now though...

You asked, "Are there still have SSL encryption between the web browser and the web server?"

Only if your /etc/resolv.conf contains a search directive as follows + you have a wildcard cert...

search abc.com

Select allOpen in new window

Things to remember about certs.

1) Certs only cover valid host/domain records which resolve to a public IP.

2) So the first challenge is intranet.abc.com, likely the intranet host has a private network (non routable) IP, so certs will never work as you expect, unless you use a wildcard cert, because this is the only way to ever generate a public cert to cover private network hosts. At least the easy way is to use a wildcard cert.

3) I do this very simply by generating free https://LetsEncrypt.org for every project. At this point, across all machines + sites this is many 1000s of certs... all free... all auto renewed by a simple CRON job, so no yearly regeneration + setup anymore. A serious time saver for 1000s of certs.

4) Once your wildcard cert generation + updates are working, a simple daily rsync CRON job does the rest of the work...

So on your machine generating wildcard certs, you just run certbot-auto renew daily.

Then on all machines using certs a daily CRON job of something like...

rsync -av -e "ssh -i path-to-your-key" --copy-links $user@$host:/etc/letsencrypt/abc.com/live/. /etc/apache/ssl/abc.com/. ; service apache2 reload

Select allOpen in new window

This CRON job breaks all the remote cert file symlinks, returning the actual files, which land in some local directory.

Since doing a reload of apache (rather than restart), leaves all in flight requests intact, all current requests finish, so no outages ever occur.

5) Once this is all setup, it works forever. In fact it works so good, I had to look at my CRON jobs to remember how I did all this setup, because the setup works 100% of the time, producing any number of wildcard certs... hands free forever...

6) At this point, the cert files can be copied anywhere + cover any host correctly whether the host has a public address or private/local address.

1) Certs only cover valid host/domain records which resolve to a public IP.

Anyone can spin up their own internal PKI infrastructure and issue certificates for their internal servers. External CA's will also issue certificates for a server not attached to the Internet. There are no problems doing this.

So the first challenge is intranet.abc.com, likely the intranet host has a private network (non routable) IP, so certs will never work as you expect

Certs work exactly the way you expect. Having a private non routable IP is irrelevant. If the SAN list covers off the host, the cert is valid for that host FQDN. This is how certificates work at a host level.

unless you use a wildcard cert, because this is the only way to ever generate a public cert to cover private network hosts. At least the easy way is to use a wildcard cert.

This is not true. To receive a certificate the CA requires a CSR. A CSR can be submitted in many ways but the 2 most common methods for a public CA certificate (DigiCert, Lets Encrypt, etc.) is via a web browser or API call. Again, there is no requirement that the server the certificate needs to ultimately be installed on have a public IP or be publicly contactable. Even for Let's Encrypt it is relatively straightforward to build a process to request external certificates for internal hosts. Let's Encrypt make it easy because their validation process is about as basic as it gets (DV). There is no requirements for OV/EV level validation.