3 ms·

Self signing, or if your feeling fancy issue from your own CA and import the root cert on your clients. If they're internal services the namespace and the trus

Self signing, or if your feeling fancy issue from your own CA and import the root cert on your clients. If they're internal services the namespace and the trust heirarchy can be private just fine.

geofft 9y ago
Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently, and second, you have to get your config onto every device on the network. If you let personal devices on the network or even just hard-to-configure things like Chromecasts, you have to get your config onto all of them somehow. It's quite a bit simpler and more secure to just use .corp.example.com or whatever.
- FooHentai 9y ago
  >Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. Sure, it's most suitable for a homelab where you can import the certs, with suitable discretion, for yourself only. >Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently Not a massive concern since the context is internal only, but I hear you. >and second, you have to get your config onto every device on the network. Yep, this can be tricky in a less controlled environment. I had two scenarios in my mind - Home lab, and enterprise, when I penned that response. There's definitely a third one here, that you have in mind, that I didn't cover. >It's quite a bit simpler and more secure to just use .corp.example.com or whatever. Definitely the best option for small to medium companies.
- Spivak 9y ago
  > I don't really trust myself to run a CA competently... You don't have to deal with any of the issues of public CAs because you control all the machines, running one in a corporate environment is no issue at all and there are plenty of existing products that will do almost all of the work for you. > you have to get your config onto every device on the network Which is a single task in an Ansible playbook, Puppet module, or Task in the Windows Task Sequence. > you have to get your config onto all of them somehow Usually not, you just need to get your CA on all the devices that are going to connect to your hosted services.

Self signing, or if your feeling fancy issue from your own CA and import the root cert on your clients. If they're internal services the namespace and the trust heirarchy can be private just fine.

geofft 9y ago

Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently, and second, you have to get your config onto every device on the network. If you let personal devices on the network or even just hard-to-configure things like Chromecasts, you have to get your config onto all of them somehow. It's quite a bit simpler and more secure to just use .corp.example.com or whatever.

FooHentai 9y ago
>Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. Sure, it's most suitable for a homelab where you can import the certs, with suitable discretion, for yourself only. >Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently Not a massive concern since the context is internal only, but I hear you. >and second, you have to get your config onto every device on the network. Yep, this can be tricky in a less controlled environment. I had two scenarios in my mind - Home lab, and enterprise, when I penned that response. There's definitely a third one here, that you have in mind, that I didn't cover. >It's quite a bit simpler and more secure to just use .corp.example.com or whatever. Definitely the best option for small to medium companies.
Spivak 9y ago
> I don't really trust myself to run a CA competently... You don't have to deal with any of the issues of public CAs because you control all the machines, running one in a corporate environment is no issue at all and there are plenty of existing products that will do almost all of the work for you. > you have to get your config onto every device on the network Which is a single task in an Ansible playbook, Puppet module, or Task in the Windows Task Sequence. > you have to get your config onto all of them somehow Usually not, you just need to get your CA on all the devices that are going to connect to your hosted services.