Certificate used to sign package is not trusted. Use -allowUntrusted to override.

[hrhnick]

We are in the middle of a Printer rollout.

I know not ideal, but I have policies in Self Service that installs the driver, then runs a single lpadmin command to map the printer.
The driver is a universal driver provided by Toshiba.
It had been working without issue yesterday, but now the policy fails and the log reads:

Installing ToshibaEStudioDriver.pkg...
Installation failed. The installer reported: installer: Package name is TOSHIBA e-STUDIO Color MFP
installer: Certificate used to sign package is not trusted. Use -allowUntrusted to override.

Any ideas on how to force this policy, or what could have changed overnight?

[mm2270]

Hi @hrhnick
Before attempting to work around this certificate issue, I would head over to Toshiba to see if they have an updated package you can download for these drivers. Package installers from known commercial developers have signed certificates in them that are trusted and the Apple installer can check on. If the embedded cert has expired or been revoked for any reason, it will see this and not allow the installation to take place unless you choose to override it. This is a security precaution, to prevent you from installing a potentially compromised or damaged installer package on your Mac.
So, first check to see if Toshiba has corrected this with a new pkg install. If there is one, download it, upload to your Jamf instance and swap the old one out for the new one and try it again.

If there is no new package, I would try to contact Toshiba support on it to see if they are even aware of a bad cert in their package and if they plan on releasing a new one. If that doesn't work, then the only recourse will be to do some workarounds for this one package. While I don't really recommend this, if you are for sure certain this package installer is legit and was not causing any issues before, you can do the following.

Copy the installer package into a new folder in /private/tmp/, such as /private/tmp/Toshiba/ or something like that.
Open Composer and drag the new folder from tmp that has the pkg installer in it to the sidebar to create a new package source. Composer will copy it in and the contents.
Adjust any permissions on the package as necessary. It's usually fine to copy down the permissions on /tmp/ to the folders below it to match.
Open the package disclosure triangle in the sidebar to reveal the Scripts section. Right/Control click on Scripts and choose Add Shell Script > PostInstall
Now in that new PostInstall script, add something like this to it.

#!/bin/sh

PKG="/private/tmp/Toshiba/PackageName.pkg      ## Adjust "PackageName.pkg" to match the actual name. Make sure to include the ".pkg" extension

## Install the pkg with the -allowUntrusted flag
/usr/sbin/installer -pkg "$PKG" -tgt / -allowUntrusted

Now build this out as a new PKG installer, upload into Jamf and replace the other installer in your policy with this new one and try having the policies run again.

The above script will use the installer command to install the pkg inside the folder using the mentioned -allowUntrusted flag, and it should install, hopefully. It's been a while since I've needed to use something like this, so I can't be 100% sure how current OS versions will work with it, but, as of Mojave, -allowUntrusted is still a valid flag in the man page for installer, so it should work.

[hrhnick]

I ended up reuploading the same driver package and it started working again... weird.

Thank you for the details though. If this package "corrupts" again I will rebuild it using your steps.

[dba_nc]

We had a problem like this in my environment - it turned out to be expired Jamf cert on a few clients. We re-enrolled the affected machines to resolve.

[jonathan_mcc]

I have the exact same issue today - yet to try responses but after heading to Toshiba's website and getting the latest drivers, it looks like their Developer certificate expired yesterday...🤦🏼‍♂️

[ccsshelpdesk]

Let me guess this happened yesterday?
As I was imaging a room after SSD upgrades yesterday and had the same issue with out ToshibiaMFD driver .pkg package. And it was running fine on Monday as I had done another room.

I have to do the following from this thread:
https://www.jamf.com/jamf-nation/discussions/4113/fixing-packages-with-expired-signatures-heads-up

These commands expands and then re flattens the pkg while removing the cert all together.

$ pkgutil --expand ThunderboltFirmwareUpdate.pkg /tmp/thunderbolt.pkg
$ pkgutil --flatten /tmp/thunderbolt.pkg ThunderboltFirmwareUpdate.nocert.pkg

Working fine for me now, as we are getting a new fleet next year so will upgrade to new drivers at that point.

Cheers

[gabester]

I may have to resort to a scripted method above; however it seems a poor direction for something that a) Apple could fix and b) Jamf could provide workaround for. I don't want to be writing custom scripts for every package, but when the first party vendor itself fails to update recently released but now invalidly-signed software, it is very discouraging for the ecosystem as a whole.

Raising this as either Jamf needs an allowUntrusted flag or Apple needs to get their act together and rerelease packages with updated signing certs. 2019's #packagepocalypse has taken too much of my time for the things that were released since September 2019... Security Updates, Safari Updates, OS installers including for Catalina.

All I really need is a properly signed Sierra Security Update 2019-005... but this version https://support.apple.com/kb/DL2013 is still from Sep 23rd, 2019.

[KSibley]

We have also seen this error in our policy to install Apple Java. I think it has to do with the expired Apple certificates issue.