Device Signature Error

[msample]

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.

[jamsheed]

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?

[ehendricks]

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!

[pkerobinson]

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.

[dpratl]

Hi @pkerobinson,

Thanks!

sudo jamf enroll -prompt

Did the trick for me :)

BR
Daniel

[stevewood]

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 -prompt method.

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.

[Morningside]

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 8.8.8.8 before enrolling is the key to success here :P

[dgreening]

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.

[Morningside]

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.

[rfreeborn]

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.

[apizz]

@rfreeborn did I see correctly that the the -reenroll and/or archiveDeviceCertificate components are new as of 10.14.0?

[patgmac]

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

[kerouak]

@patgmac
Do you mean the database table 'jss_custom_settings'

[patgmac]

@kerouak I really don't know. That was a long time ago and someone else implemented the fix.

[mthakur]

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[72190]: 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?

[mthakur]

I asked:

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[72190]: 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?

[LRZ_Jamf]

Nope, we have some devices too with similar errors.
I hope our Upgrade to 10.19 made it better.

[drhoten]

Hello @mthakur

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?

[hepvd]

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.

[JCMBowman]

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.

[kerouak]

and here we go again!

[kerouak]

cant access self service... Sudo jamf recon.. Device etc etc.. Really??

[MrRoboto]

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?

[MrRoboto]

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.

[mapurcel]

@kerouak @MrRoboto I'm also starting to see device signature error, it seems only since we upgraded to 10.28...have you learned anything more about what might be causing this?

[dng2000]

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.

[prbsparx]

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.
Kinda strange...

[dng2000]

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.

[jwild]

I was able to fix the issue by running 

sudo profiles renew -type enrollment

After that, I could successfully run 

sudo jamf policy