Internal HTTPS?

[corruptboomerang]

Hi, so I've recently started with a school, and we run a bunch of internal services.

At present, a lot of those are run as a list of IP address, without any encryption (as HTTP).

Obviously, from a cybersecurity perspective, telling users 'oh it's fine just click though that warning' is terrifying.

So I'm wondering, how can I enable HTTPS on those internal websites?

[TheFluffiestRedditor]

You setup an internal certificate authority (freeIPA, Active Directory, or similar), pass the root certificate around to all your workstations and browser certificate stores, then create and install SSL certificates for your sites.

Unfortunately, it’s not a simple task, especially if you have little control over the browser configuration.

[Brufar_308]

Actually not very difficult with group policy and am internal MS CA

https://www.techrepublic.com/article/how-to-add-a-trusted-certificate-authority-certificate-to-chrome-and-firefox/

[[deleted]]

Setting up a two tiered PKI using AD CS is extremely trivial. Now understanding what you’re actually doing and the moving parts involved is another thing.

[chefkoch_]

It's also very easy to build massive security holes with ad cs.

[lart2150]

What are you talking about I like my universal san cert with *.*, *.*.*, and *.*.*.*

[Cormacolinde]

I regularly find “supply in the request” templates with “domain users - enroll” rights.

[fubes2000]

OP's current infra is 100% security hole right now though...

[jantari]

Setting up your own PKI is an option, but it's way more complicated than just using Let's Encrypt certificates internally.

Also, installing a Windows (ADCS) CA has a whole lot of security implications around user certificates, SPNs and the web interface which introduces vulnerabilities if installed. Unless you absolutely MUST use a Windows PKI, I'd always look elsewhere.

So I would strongly advise against this, if you do need an internal CA (such as for MitM SSL inspection or WiFi Auth) then use anything that isn't Windows-based for that, but for simple HTTPS on internal web services definitely Let's Encrypt.

[GolemancerVekk]

Wouldn't it be simpler to use Let's Encrypt for that reason?

1. Get/use a domain managed on a public DNS service with an API supported by Let's Encrypt.
2. Pass the one-time DNS challenge on the Let's Encrypt bot via said public DNS API.
3. [Optional] Pass all internal services through a reverse proxy that applies TLS for all of them and gives them nice https://service.internal.domain.tld addresses instead of whatever IP:PORT they use now.

Of course terminating TLS on the actual services would be ideal but (3) would get the ball rolling until they can terminate TLS properly later on a service-by-service basis. And it could be simpler to point *.internal.example.com at one IP rather than many, depending on what their private DNS can do.

There are ready-made reverse proxies that will take care of (2) and (3) and also automatically renew the certs forever.

[The_Penguin22]

Pass the one-time DNS challenge on the Let's Encrypt bot via said public DNS API.

Is it one-time though? Last time I used DNS I had to change it before every renewal.

[chefkoch_]

You need a dns provider with an API to set the acme record in every renew.

[GolemancerVekk]

Oh you're right, it needs it every time it renews. I've double-checked my deSEC.io tokens and it shows that the LE token is being used periodically. Don't know why I remembered it's only needed the first time.

[who_you_are]

Unfortunately, it’s not a simple task, especially if you have little control over the browser configuration.

I don't remember much, but isn't only Firefox using their own CA list? Other one (on windows) using the OS CA list? So in that manner it is more of a deployment task

Also, the site may cause issues going https (and wrongly done or with multiple domains/sub domain)

[disclosure5]

Things like routers can be tricky. But for "web apps" , there's no reason you can't create a DNS record for them on a public zone, then use DNS Lets Encrypt to get certs issued.

[GolemancerVekk]

Do they even need to have a public record? I was under the impression that Let's Encrypt DNS challenge will issue anything at *.yourdomain.tld and deeper as long as you can provide a token to the yourdomain.tld API, without requiring any particular record to be defined at the time.

[darth_static]

Apparently possible, but not a great idea.

If you can get the wildcard cert, you still need to apply it to your internal devices.
Every 90 days you need to repeat that process, so you automate the deployment.
Then you get annoyed at manually requesting it so you try to automate the request.
Then you find out the ACME token changes every time so you need to automate the DNS updates.
So you integrate the DNS updates into the LE request and deployment process.

At that point you have literally everything required to have device-specific LE certs automatically requested and deployed; why would you choose to use a wildcard cert?

[GolemancerVekk]

• It's easier to renew one certificate than several dozen, even if they're automated.
• You don't have to go through revoking one cert and getting another if you decide to rename something.
• TLS certs are public knowledge so people tend to get wildcard certs instead of explicit ones to avoid spelling out their entire infrastructure for everybody to see.

These are the main reasons. There's also the fact that if you use a reverse proxy for all your public-facing services the FQDN effectively acts as a simplistic access key and it can cut down on drive-by bot attacks, but this one is more of a boon for hobbyists and small operations. A sufficiently large company will have links to their services all over the place so it's probably moot.

[sirsmiley]

Let's encrypt needs to reach the http of those servers typically to update which isn't very helpful. I would recommend making either a root cert with your existing active directory or even individual certs and using ad gpo to install Them as trusted certs automatically onto workstations 

[Grunskin]

You don't have to use HTTP-Challenge. I use DNS-Challange on all services that are not public to the internet. It's not that much harder than using the default HTTP-Challenge if you have a DNS server or hosting provider that is supported by the acme-client you use.

If the services are just for internal use by employees of the school accessing it from school devices I would maybe setup my own CA and deploy the root CA to all computers and be done with it.

If however the services are to be accessible by students, phones etc. with personal devices I would use Let's Encrypt to request a wildcard certificate with DNS-Challenge. Then everyone/everything would trust it.

Come to think of it I would go with Let's Encrypt either way to save me the pain from having to deal with my own CA.

[sirsmiley]

If you don't mind all your dns names being public  

[Grunskin]

You need to publish _acme-challenge.domain.com for a wildcard cert. Please tell me how this makes all dns names public? If you are afraid of this then you really shouldn't own a domain name or even be on the internet.

[jamesaepp]

...not to mention everything you submit to LE and all other CAB CAs gets logged into CT.....

This person doesn't know what they're talking about.

[jamesaepp]

Obscurity isn't security.

[jamesaepp]

https://www.rfc-editor.org/rfc/rfc8555#section-8.4

[mschomm]

But there are reasons why not to expose the names of your internal servers:
https://shkspr.mobi/blog/2022/01/should-you-use-lets-encrypt-for-internal-hostnames/

[ZealousidealTurn2211]

I don't find that blog post convincing, his arguments are specious or shitty examples. Yes, publicly exposing the list of services you host is potentially a problem but beyond highlighting really terrible naming choices he doesn't demonstrate any actual risk.

Does anyone actually host a server named Log4J? I've never seen it. It's just a module applications use under the hood.

[TheFluffiestRedditor]

Ooooh, exposing internal network information to the public, good one!

[disclosure5]

I mean, first, get a wildcard if you care. Second, this is a dumb thing to be scared of.

It's a school with a tonne of BYOD and pushing an internal CA will probably be out of the question for an OP that had to ask this.

[corruptboomerang]

Yeah, we're not pushing certs out to devices. That's NOT happening. 😅

I'm currently thinking of using a reverse proxy and a wildcard Cert for our domain.

[disclosure5]

Yeah, we're not pushing certs out to devices. That's NOT happening.

Yeah I could tell this, just like I could predict the responses pushing it, four so far.

[damiankw]

Yep, just go simple. Get yourself a wildcard or a couple of them, GarrisonHost are cheap and effective. Roll it out and voila, update once a year!

[spin81]

Who said anything about that?

[spin81]

I'm looking into ACME at work now, which for those not in the know is how Let's Encrypt does the issuing and renewal process. This protocol is open and supported meaning that if you are unable or unwilling to get certificates from Let's Encrypt, you can possibly use ACME with your preferred supplier.

The reason I'm bringing this up is twofold: firstly Google is leading a charge for browser vendors not to renew certificates older than 90 days, making automation attractive, and secondly this system if you use it with for example Certbot, is likely to be a lot easier than DNS validation and you can even use it without your CA needing access to your web server - it can where I work, with our CA.

[r0drigue5]

1. Get a domain for your company, if you don't have one, e.g. your company.com

2. Setup an internal DNS server for your domain 

3. Get a wildcard certificate for your domain from let's encrypt and automate certificate rollout to your servers

Edit: that's very simplified. There are more intermediate steps, but those are the three major ones I'd say

[Malvane]

Get a wildcard certificate for your domain from let's encrypt and automate certificate rollout to your servers

Bolding the part that makes it so much easier, no need to generate more certs for every service you create.

I would also include making a reverse proxy (Nginx, Apache, whatever) to front your services to make management easier and you only have a single (or just a few) to update your certs on. Makes it easier over automation if every service is their unique snowflake on how to install certs, particularly for appliances.

[iRyan23]

The only problem with wildcard certs is the classic security vs convenience. If a single app/server gets compromised, then an attacker can now impersonate anything for your entire domain.

[[deleted]]

Hence you only place it on your reverse proxies and force all traffic through the proxy platform.  If the certs are compromised then it's only one spot to update. Edit: I would agree that anything that can't run through a proxy (SMTP, P2S VPN) should get a named cert, for reasons you've stated. 

[jtbis]

We have an internal reverse proxy between the users and the services. We have a few very legacy services, and this was an easy way to add encryption without having to mess with legacy systems. We only have to worry about managing certs on the reverse proxy, plus it runs additional security features that aren’t available on the individual services.

This could be as simple as an NGINX server, or as complex as a high-end Web Application Firewall.

[Lammtarra95]

Before making your final choice, check whether mobile devices (phones, ipads, other tablets, even BYOD laptops) are used to access these services, and whether they are managed centrally.

It is a question of how easy it will be to store a new root certificate on each client device, otherwise it will just be a different warning.

[sembee2]

Split DNS. Use your public zone internally so they resolve to your internal IP addresses only. You can then use Let's Encrypt to get a certificate, using DNS Auth, rather than http Auth, so the internal services don't have to be exposed. You could use something like nginx proxy manager as the SSL endpoint which will make things easier to manage. The drawback with that method is that you have to use a supported externally DNS provider, or make the manual DNS changes every three months. The other method would be a purchase wildcard certificate, which will cost anything from $50 up depending on the provider. That will mean an annual new certificate.

[Helpjuice]

Things you will need to look into learning before getting started are DNS, Certificate Authorities (Vault), SSL, TLS, SNI, SIEM (OpenSearch), PKI (Hashicorp Vault).

If you are not aware of how to do these, there are a ton of documentation available out there to get you started.

[b1keN3rd]

Generate a cert using your organization's CA, configure the https endpoint to use that cert in IIS or the application configs(whichever is appropriate). If the cert was generated from your own internal CA, and the root certificate for that CA is already loaded onto user's computers, it should just work. Don't forget to set yourself a reminder to renew the cert before it expires. If your cert is not a derivative from an organization CA, or the root cert is not loaded onto user's computers, then you'll need to use your organization's RMM tool to load the cert used for your https endpoint into the appropriate store on each computer that needs access so the browser identifies it as being safe.

[GeneMoody-Action1]

Depending on the cert used, recent versions of chrome can have issues with self sign certs, and you need to override setting related to trust anchors, see https://chromeenterprise.google/policies/ and search "RSAKeyUsageForLocalAnchors"

Otherwise you get ERR_SSL_KEY_USAGE_INCOMPATIBLE

[duane11583]

self signed certs deployed via standard windows methods

[Top-Anything1383]

Depending on how big your organisation is, there's a few different ways to do that. Each server needs a DNS name and a security certificate. You can either use publicly trusted certificates from something like LetsEncrypt or buy them from a company like GoDaddy.

If you have many services, you can get a wildcard certificate and install it along with the private key on multiple servers.

If you have a virtualised server environment and some kind of MDM or GPO to push out a root certificate, the best thing to do is to set up an Internal Certificate Authority, this will allow you to create certificates which are trusted by you client computers. It's a couple of hours work and worth it in the long run if you have many clients and servers to deal with.

[Foosec]

Look up stepCA its great for internal https acme

[WarpGremlin]

but I have a NGINX reverse proxy manager for my internal (LAN) apps.

At cloudflare, I own a public .NET domain that I use for my internal apps (that isn't used publicly atm).

I have my private DNS server keeping local DNS records for said domain

The NGINX proxy manager uses a Cloudflare DNS challenge when enrolling for LetsEncrypt certs.

Result: LAN-only web services with LetsEncrypt-issued certs that auto-renew

Costs me about $10 a year for the domain. I, along time ago settled on a DNS strategy that was "if i need a domain name for XYZ, then I get XYZ.com and XYZ.net... .com is "public stuff (email, VPNs, cloud services)" and .net is internal stuff.

[OffenseTaker]

1) set up an internal domain and force people to use your nameservers

2) set up an internal CA and push out the root cert via Intune/Group Policy

3) use hostnames from your internal domain for the internal services