Root Cert Woes. Advice Appreciated

rickwhois
Contributor

Hi there, I'm in root cert prison. I don't know how this happened, but something went awry in the past month and our newly imaged clients root certs are out of whack. Should I seek help from our TAM or are there any cert pros out there?

Scenario 1: Newly Imaged Client Build
1. I build a OS X 10.11.1 dmg using AutoDMG and upload to jss via Casper Admin.app.
2. I create and deploy a Configuration to a client via Casper Imaging using an nbi made with AutoCasperNBI (10.10.5)
3. Once image is complete, I login using our management account. Self Service.app installs and it gets policies from the jss.
4. Apps signed by developer id's are not installing because of expiring cert. however the certs are not expiring.
Log> Verifying package integrity... Installing JavaAppletPlugin.pkg... Installation failed. The installer reported: installer: Package name is JavaAppletPlugin
installer: Certificate used to sign package is not trusted. Use -allowUntrusted to override.
5. When I run the JavaAppletPlugin.pkg installer manually I receive the following when viewing the signed cert.

dca13a7d4ec6408f83953883225942d3

Scenario 2: (Internet Recovery Build)
1. I run internet recovery and use disk utility to format drive and install the shipped operating system
2. I take note that the file JavaAppletPlugin.pkg is validated and runs as expected.
3. I enroll into Casper via https enrollment.
4. Signed JavaAppletPlugin.pkg continues to work and run as expected. Root cert is validated and all is good.
6feecf063c2c4e24968691607eddc892

Here are things I've done to be proactive.
1. Renewed MDM push cert
2. Generated a new certificate from the JSS's built-in CA and restarted TomCat
3. Removed p12 Developer ID Installer cert and rebooted, re-uploaded the p12 Developer ID Installer cert and rebooted

Any help or advise is so very appreciated as I'm at my wits end

4 REPLIES 4

bpavlov
Honored Contributor

I have seen this happen before when you have the developer certs for packaging signing installed. It caused so many problems on my machine and no matter how closely I looked in keychain I couldn't get it resolved. Signed packages just wouldn't install correctly via the command line unless you allowed untrusted packages. I re-imaged my machine and no longer deal with it. I make sure to install any developer signing certs on a VM.

Just out of curiosity why are you installing the Developer ID installer cert on these machines? Casper shouldn't be pushing it out so I'm guessing there's a policy that is doing that.

rickwhois
Contributor

@bpavlov thanks for your reply. i only upload the developer id installer cert to the jss. that way it signs the quick add.pkg for self enrollment.

i also install the dev id installer cert on my own mac but that is so i can sign self made pkg's.

The thing i'm running into is that on a newly imaged machine (dmg made with autodmg) with nothing but the OS and jss enrollment, it seems that the Apple Root CA is not acknowledged on these newly images machines. However it does appear in keychain.

This issue does not occur with a factory imaged machine

I'm puzzled :(

rickwhois
Contributor

i guess it would be good to note that the javaappletplugin.pkg is signed by oracle and straight from java.com. but this happens with everything signed by any dev id installer.

rickwhois
Contributor

crisis averted :) just thought i'd share what resolved it in case anyone else runs into this. After reaching out to jamf support, they suggested stripping out all pkg's from the deploy config. After removing some scripts we had set to run at enrollment, the cert issue disappeared. I will instead put this scripts in a first boot pkg.