Best Practice JSS Certificate

[dooley_do]

Hi,

I was going to use a certificate issues by our AD CA for the JSS but I realised that then when enrolling a device the jamf binary would not connect because a Mac which is not domain joined does not trust our CA, so I would have needed to install those root and subca certs onto the Mac first. So for now I am using the self signed cert.

What is the best solution for this or do people just run with the JSS self signed?

Thanks

[m_entholzner]

Personally, I think that the JSS self-signed cert is totally fine. There's not really a reason for not using that. It makes it simpler so change the SSL cert when needed, because it can be created right in the JSS webapp. The cert is automatically trusted on enrolled Macs, so no need to do that manually.

[jarednichols]

Self-signed certs are as good as a stranger on the street saying, "Let me hold your wallet. You can trust me."

They're good temporarily but you should really get a cert that is trusted. Either one from an internal CA that all systems in your org trusts or from a well-known external CA.

Self-signed certs can also introduce unexpected problems. Most clients warn about connecting to a session secured with a self-signed cert, some need a setting change to connect. Still others refuse to connect a self-signed session completely.

To eliminate these occasional issues that may take some time to figure out, get a trusted cert.

[m_entholzner]

We could start a discussion now if self-signed or "trusted" certs are more secure :)
In fact, every "trusted" cert has a root CA which holds your private key. If it's your own root CA, totally fine. If it's an CA of VeriSign or someone else, I must not mention that the NSA and other goverment organizations can and will get access to your private key. So, in my opinion, a self-signed is as much as secure as a so-called trusted cert. Because YOU are the only one which holds your private key.

[chriscollins]

For us it's about the user experience so we use a 3rd party signed cert. Since we have a lot of users who have to self enroll through user initiated enrollment we don't want them getting prompted by untrusted cents when they visit the enrollment url especially when we spend time telling them to be wary of trusting random self signed certs so it's not a bad habit we want to help re-inforce in them.

[jarednichols]

In fact, every "trusted" cert has a root CA which holds your private key. If it's your own root CA, totally fine. If it's an CA of VeriSign or someone else, I must not mention that the NSA and other goverment organizations can and will get access to your private key.

Slow down there. This is not even remotely close to true.

Perhaps there are some hosting companies and such that will make the job easier for you and maybe that lets the private key out of the bag, but if you're the one (manually or programmatically) doing the

openssl req -new -newkey rsa:2048 -nodes -out myserver_mydomain_com.csr -keyout myserver_mydomain_com.key

or equivalent for your platform (keytool etc...) you absolutely retain the private key. If private keys were sent along in this manner, there'd be a far bigger shit storm on government surveillance than there already has been and the US and UK governments wouldn't be lobbying their respective legislatures for laws weakening encryption through FUD -- because they'd already have the keys.

[bentoms]

@dooley_do this might not be best practice.. but it makes life easier for me! Our JSS cert is a wildcard cert & is signed by a 3rd party.

The benefit of this is that we can use the same cert for test, dev & prod.. which the lazy admin in me likes.