[15thandwhatever]

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.

[zimbatm]

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.

[tomjen3]

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

[zimbatm]

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.

[tomjen3]

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

[Lazare]

> 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.

[mattowen_uk]

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~

[cm2187]

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

[ewanm89]

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.

[ptman]

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

[skywhopper]

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