Posted on 03-24-2015 02:02 PM
Upgraded from Casper 9.62 to 9.65, but started experiencing trouble when running recon via terminal. Anyone else run into this?
"Device Signature Error - A Valid device signature is required to perform the action.
Solved! Go to Solution.
Posted on 04-17-2015 09:12 AM
Posted on 01-04-2019 04:43 AM
I am facing this issue a lot. I have enrolled about 36 macbooks till now, out of which about 10 of them went into this stage. 2 of them automatically got resolved after sometime, but others seems to be stuck until i run a removeframework and reenroll them. Any better ideas?
Posted on 05-07-2019 08:53 AM
This has happened several times with our Mac enrollment via DEP. It is not consistent, however, and it has been tricky figuring out a root cause. With a handful of laptops, there was a certificate error and the device never checked in with the JSS.
What has definitely worked for individual laptops is executing the following Terminal command on each device:
sudo jamf enroll -prompt
Then, you can run sudo jamf recon and/or sudo jamf policy to update records and push policies.
Hope that helps!
Posted on 05-09-2019 06:10 AM
Yes. Seeing the exact same thing. Two out of seventy-five MacBook Airs that we just reimaged came up with the error, and we've seen similar numbers with previous deployments. Running sudo jamf enroll -prompt has worked every time for us.
Posted on 05-23-2019 06:56 AM
Posted on 05-23-2019 07:34 AM
Even easier than
jamf enroll -prompt is to create an Enrollment Invitation (paper airplane icon) that never expires (put the date out as far as you can) and is re-usable. Take the invitation ID that is created then you can do
jamf enroll -invitation <invitation ID>. That way you do not have to enter any more dialog like you do with the
The only downside is that if you put a valid email address in the invitation, that user is put in as the username. At least in our environment that's what we see. So just do something like "a@a" and you get past that.
Posted on 06-11-2019 01:26 PM
I am getting this error on at least half the macs I am manually enrolling. In may case, as it turns out, I am being inadvertently caught in our DNS filter. Setting DNS to 188.8.131.52 before enrolling is the key to success here :P
Posted on 06-11-2019 01:36 PM
Question for you all: in the local jamf.log at enrollment, do you see ONE or TWO certificate errors? If it is two... well, you might be running into a PI which was introduced in Jamf 10.9.
Posted on 06-11-2019 01:39 PM
I'll take a look during the next enrollment. All of the current machines I am working on have been enrolled, and reenrolled, and have had multiple Device Sig errors so I wouldn't trust those logs. On my next clean one though, I'll take a look.
Posted on 08-01-2019 08:49 AM
I too have used the jamf enroll -prompt to fix this issue with some success but only problem with it is, if the device is sited it will re-enroll the device and fix certificate but device will be un-sited. Simple enough to re-site in the JSS on the computer record, but not ideal. So I moved to using the sudo jamf enroll -prompt -reenroll -archiveDeviceCertificate that @aporlebeke references which of course you still have to enter the JSS Username and Pass and SSH Username and Pass, which is a pain. So I then modified it to use the enrollment invitation ID that @stevewood talked about, and used that in terminal for a while but it was still became a pain to type or paste after entering necessary su and sudo on a standard user who's logged in because of the rather long syntax. So I decided to set it up as a self service policy using the execute command in Files and Process section of policy. I just pasted the command sudo jamf enroll -id <invitationIDNumber> -reenroll -archiveDeviceCertificate then set the policy to be available ongoing and then set an update inventory in Maintenance section of policy and made it available in Self-Service in our Software Update and Maintenance category. Then whenever we run into the issue we can just enable the policy, open up Self-Service on the device and run it. I didn't feel it was good idea to leave the policy enabled where user might run it so we disable policy when we aren't using it. When it is done device signature error is fixed, a new inventory is submitted and the device is still sighted in JSS. Just FYI, in testing I found this can be run over and over as long as you create invitation with the multiple uses checked and in testing I didn't see any problems or issues but not sure. I think technically you could set this up as a policy to run automatically to catch any devices that might be out there with the error that are checking in but not getting inventory updates or running policies on checkins etc. If it runs on a device that is working fine, doesn't seem to cause issues. At this point we don't know for sure and we don't see the issue a lot so will just enable when we need it and disable when done.
Posted on 08-01-2019 09:03 AM
@rfreeborn did I see correctly that the the
archiveDeviceCertificate components are new as of 10.14.0?
Posted on 08-14-2019 11:23 AM
I opened a ticket on this. Was informed of:
PI-006766 - Race condition during MDM-first Enrollment causes enrollment to fail.
There is apparently a workaround that involves editing the QuickAddWatcher thread parameters in the jss_custom_settings table, and adjusting "failtime" it will increase the failure timeout to provide a longer window for the MDM enrollment process to complete
Posted on 01-09-2020 01:18 AM
Do you mean the database table 'jss_custom_settings'
Posted on 01-13-2020 01:32 PM
Posted on 02-18-2020 06:56 AM
Does anyone have a root cause analysis for this "device signature error"?
It's frustrating that this issue just bit us again this past Thursday (Feb 13, 2020):
Thu Feb 13 12:36:31 xxxxxxx jamf: There was an error. Device Signature Error - A valid device signature is required to perform the action.
Is this caused by an expiring certificate? Which one?
Posted on 02-18-2020 07:20 AM
Is this [device signature error] caused by an expiring certificate? Which one?
Answering my own question, yes, this error started when this certificate expired:
$ sudo security -i find-certificate -a -p /Library/Application Support/JAMF/JAMF.keychain > /tmp/jamf.pem $ openssl x509 -in /tmp/jamf.pem -noout -subject -issuer -dates subject= /OU=JAMF Device Certificate/CN=B303F0CB-3FF8-5FE1-9EC9-940648E3C7BF issuer= /CN=<organization name deleted> JSS Built-in Certificate Authority notBefore=Feb 11 17:12:00 2015 GMT notAfter=Feb 13 17:12:00 2020 GMT $
Note the expiration date of "Feb 13 17:12:00 2020 GMT."
This is exactly when the issue started (converting GMT to local timezone):
Thu Feb 13 12:36:31 xxxxxxx jamf: There was an error
The question now is:
Why is this JAMF device certificate, wholly issued and controlled by the JSS, not being updated automatically by the JSS?
Of course, we're still running an old version (9.101.0), and yes, we're planning to upgrade it to v10.19.0. Is there any assurance that the newest version of JAMF Pro will handle these internal certificates more cleanly?
Posted on 02-20-2020 05:30 AM
Nope, we have some devices too with similar errors.
I hope our Upgrade to 10.19 made it better.
Posted on 02-27-2020 11:51 AM
You are correct, today there is no mechanism in Jamf Pro to automatically handle renewing either this certificate or the device identity certificate in the MDM profile. I am happy to share we are actively working on this for an upcoming release of Jamf Pro and are looking for folks like yourself to test it out in the future. Would be you be interested?
Posted on 07-01-2020 01:14 AM
For what its worth… If it can helps :
Had the issue today, with one single computer. Remove the MDM profile and tried to enroll it back, but then I had an SSL error while trying to install the configuration.profile.
The issue was the keychain of the user which was corrupted. Removed it and everything was back on track.
Posted on 08-11-2020 12:44 PM
I've been running into the same issue on my round of fall imaging.
The fix was what @rfreeborn suggested - I created and enrollment invitation and then set up a policy to run the following command:
jamf enroll -invitation <invitationIDNumber> -reenroll -archiveDeviceCertificate
It's a little clunky having to do this one machine at a time, but it's a better fix than having to touch each one.
Posted on 04-23-2021 08:46 AM
and here we go again!
Posted on 04-23-2021 08:47 AM
cant access self service... Sudo jamf recon.. Device etc etc.. Really??
Posted on 04-23-2021 10:37 AM
Recently I've had the Device Signature issue occur on new computers enrolments or existing computer wipe/enrolments. Trying to run any Jamf command fails, packages fail to install. If we let the computer sit for 5-15 minutes the error goes away and everything is normal. Possibly a delay in JSS updating the computer certificate for the device record?
Posted on 04-23-2021 10:39 AM
Another issue... on some enrolments everything works okay except for Self Service, all policies get stuck on executing. Running the Jamf Manage command fixes things right away.
Posted on 05-05-2021 02:41 PM
Posted on 06-05-2021 03:47 PM
I reproduced the 'Device Signature Error' problem via Migration Assistant in my test lab and the following command resolved that problem successfully on the DEP-enrolled test Mac: sudo profiles renew -type enrollment
I haven't tested that on actual users affected by this but I'm confident it'll work since it did on my test Mac, which is a MacBook Pro M1 on ADE in ASM with user-removal of MDM profile disallowed.
Posted on 06-10-2021 12:02 PM
I just got a report of this from a user running macOS 11.4, we're running Jamf Pro 10.26.1 currently.
None of the commands we've tried so far have worked.
Posted on 06-15-2021 05:36 PM
I haven't had time to test this more but I discovered the best way (for me at least) to reproduce Device Signature Errors for testing purposes is just deleting the computer's record in Jamf Pro.
Posted on 06-29-2022 03:25 PM
I was able to fix the issue by running
sudo profiles renew -type enrollment
After that, I could successfully run
sudo jamf policy