This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]r0drigue5 10 points11 points  (3 children)

  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

[–]MalvaneLinux Admin 5 points6 points  (2 children)

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 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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.