Large companies do this.

Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy.

I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?"

I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?"

I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.

Google is moving away from network-centric security and VPNs. See https://cloud.google.com/beyondcorp/ . The threat model is a bit different but you could also follow their approach and put an auth proxy in front of Jenkins and deploy it on the public Internet.

But yeah, don't expose Jenkins to the Internet directly. Last month I saw a Jenkins instance that was mining bitcoins. The worm had used one of Java's serialisation vuln to get in the box and install the miner.

No vpn means any vulnerability can be attacked over the internet.

Not at all, it means the proxy can be attacked over the Internet. Just like the VPN can be attacked over the Internet. Once you're past that it's the same story.

At minimum that means your SSH service is also vulnerable, no?

> I replied that LE only works on external facing sites, not internal sites.

LE supports DNS validation; as far as I'm aware it now works great for internal sites.

Specifically... LetsEncrypt, and most other CAs no longer issue certs for domains that are not legal ccTLDs or gTLDs.

Not so many years ago, Microsoft recommended that organisations used [companyname].local as their internal DNS zone[1], as .local will never be an external zone, so there would be no conflict. Then along came cloud integration and increased need for edge services, and .local no worked well as a solution. Servers needed certs with both the local domain and a new external domain in their certs which became a security nightmare. Then (about a year ago) CAs stopped issuing certs for domains that weren't sub-domains of proper TLDs, which all but killed the concept of these internal non-legal domains.

So, unless you are prepared to roll your own CA, AND instruct your internal (non MS-domain members) users how to manually install an untrusted cert, signing internal sites that do not have a legal domain name, is a complete non-starter.

---

[1] Now of course they recommend a sub-domain of your public domain name (site1.company.com), or a reserved public domain name that you don't use externally (site1-company.com). Which is all well and good, but what about the 100s of legacy kit you've got on the old name... ~sigh~

LE works with internal websites. Just use DNS validation and register any public domain (costs almost nothing).

It is pretty easy to manage your own CA, make a Debian VM, install something like XCA and it is literally click a few buttons to generate and issue certificates and set up certificate authority root certificates.

FreeIPA sets up a CA by default and AD can do it as well (not sure if it's done by default).

Namecheap will sell you certificates for your internal domains, $9/year.

And why would I trust a company I work at to be able to sign certificates for every single website on the internet? Especially if I need to install that root certificate on a personal device?

Because you already trust chinese, russian and a bunch of unethical for profit companies to do that?

As a matter of fact I don't. I'm keeping track of my root certs.

If you need such a device to do your job, maybe ask them to provide one so you can keep work off your personal device anyway? I disconnected my phone and so forth from work email and other services some time ago, and I'm not going back!

Why would you need to install it in a personal device? Just add an exception. It's still better than plain HTTP since you can check the fingerprint against your work PC, which already validated the cert.

Add an exception for every single internal site? You know how annoying that gets?

This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.

If you let any student that brings their own laptop connect to it, then it's already pretty darn public.

And you don't actually have to expose it to the internet to get a certificate, you only have to give it a public name.

Additionally, if you let anyone bring their own device in a diverse semi-public environment like a school, you owe it to the students and faculty alike to provide them with some protection against creative types placing fake wifi access points in busy places, trying to play man-in-the-middle for any credentials and other stuff sent to your local services. HTTPS does that.

Using a proper FQDN for each service only makes everything easier to maintain.

You don’t need to expose them. You need to use public DNS records, but there is no reason those records have to point to public IPs.

e.g. my company uses *.int.cuvva.co which all point to IPs in the 10.0.0.0/8 block, but we still have HTTPS certificates for all of those.

> As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.

No, you just need to have a public DNS entry, no need for that service to be reachable from the internet.

foo.example.com can resolve to your private RFC1918 address, when you send the CSR to a CA, they'll verify your ownership of example.com.

A public domain name costs the price of a coffee (and less than a raspberry pi) and you can get a certificate for free with Let's Encrypt. There is really no reason to resort to a private CA unless you want to MITM your client's connection.

You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.

Even if you could I would highly recommend against doing that, given that this would grant you access to every https connection that isn't hpkp secured.

I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done.

If I can do this for me and my cat in my spare time, you can do this for your university.

> My student society for example

> need to expose critical internal services on the public internet, some of which contain private user data.

The heck? Are they aware of this? Might you get sued for this?

If you can’t control your clients - maybe use a captive portal style landing page with a link to install the local certificate or something along those lines, it’s also useful to have a wireless network (SSID/VLAN) for BYOD that just has internet access and as such doesn’t need the very and one that has access to internal services that does.

I even do this on my own private network. Installing root certificates is not hard.