Skip to main content

Hey All,

Starting a few days ago I was alerted to a communications error from our Jamf Infrastructure Manager instance.  It's been working fine for quite a while (years), and is running JIM 2.4.0 (Windows 2019 server, Java 11.17.x)

The JIM Log files clearly show the moment when things went awry April 1 @ 10:06:42, but no indicators as the nature of the issue.  I haven't yet found anything relevant in the Windows server logs.

2023-04-01 10:05:52,672 INFO c.j.i.l.LpsTransferThread [JSS->LDAP for [/54.208.14.206:8869](2803)] Transfer thread started
2023-04-01 10:05:52,672 INFO c.j.i.l.LpsTransferThread [LDAP->JSS for [/54.208.14.206:8869](2803)] Transfer thread started
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsTransferThread [JSS->LDAP for [/54.208.14.206:8869](2803)] Input Socket (JSS), end-of-stream
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsProxyConnection [JSS->LDAP for [/54.208.14.206:8869](2803)] Closing Jamf Pro socket
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsProxyConnection [JSS->LDAP for [/54.208.14.206:8869](2803)] Closing LDAP socket
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsTransferThread [LDAP->JSS for [/54.208.14.206:8869](2803)] Input Socket (LDAP), end-of-stream
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsTransferThread [JSS->LDAP for [/54.208.14.206:8869](2803)] Transfer thread stopped
2023-04-01 10:05:52,809 INFO c.j.i.l.LpsTransferThread [LDAP->JSS for [/54.208.14.206:8869](2803)] Transfer thread stopped
2023-04-01 10:06:11,888 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Initiating checkin to Jamf Pro
2023-04-01 10:06:11,951 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Checkin complete, next checkin in [30] seconds
2023-04-01 10:06:41,978 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Initiating checkin to Jamf Pro
2023-04-01 10:06:42,025 ERROR c.j.i.i.j.JssCommunicationServiceImpl [pool-3-thread-1] Problem with checkin: InvalidDeviceSignature
2023-04-01 10:06:42,025 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Checkin complete, next checkin in [30] seconds
2023-04-01 10:07:12,041 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Initiating checkin to Jamf Pro
2023-04-01 10:07:12,087 ERROR c.j.i.i.j.JssCommunicationServiceImpl [pool-3-thread-1] Problem with checkin: InvalidDeviceSignature
2023-04-01 10:07:12,087 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Checkin complete, next checkin in [30] seconds
2023-04-01 10:07:28,604 INFO c.j.i.l.LpsServerSocketListener [lps: itwvjssp02.med.harvard.edu/134.174.149.240:8636 (ssl)] Created proxy connection: [/54.208.14.206:23782](2804)-->[0.0.0.0/0.0.0.0:8636]-->[med.harvard.edu/10.120.3.8:389]
2023-04-01 10:07:28,604 INFO c.j.i.l.LpsProxyConnection [lps: itwvjssp02.med.harvard.edu/134.174.149.240:8636 (ssl)] starting connection: [/54.208.14.206:23782](2804)-->[0.0.0.0/0.0.0.0:8636]-->[med.harvard.edu/10.120.3.8:389]
2023-04-01 10:07:28,604 INFO c.j.i.l.LpsTransferThread [JSS->LDAP for [/54.208.14.206:23782](2804)] Transfer thread started
2023-04-01 10:07:28,604 INFO c.j.i.l.LpsTransferThread [LDAP->JSS for [/54.208.14.206:23782](2804)] Transfer thread started
2023-04-01 10:07:42,115 INFO c.j.i.i.j.JssCheckinManager [pool-3-thread-1] Initiating checkin to Jamf Pro
2023-04-01 10:07:42,162 ERROR c.j.i.i.j.JssCommunicationServiceImpl [pool-3-thread-1] Problem with checkin: InvalidDeviceSignature

 

In Jamf Pro, I am prompted with a warning that Jamf Infrastructure Manager has not checked in since 4/1/2023 @ 10:06 AM, and today there was a prompt that there is an LDAP Server Configuration error.

When testing LDAP lookups in the Jamf console things appear to be working as expected with no errors.

I am able to open a telnet connection between the JIM server and Jamf Cloud.

 

Anyone have any thoughts?

 

Hey @pbenware1 .  I don't have any insight as to what might be causing the error.  You could, however, rule out the JIM software (if you wanted).  I see you're on 2.4.0.  I'm running 2.2.0.  Maybe you could down-grade (?) to 2.3 or 2.2 and see if the error goes away?  Just a thought....no idea if it's worth messing with since you mentioned it's all working.  Good luck. 

Hey @pbenware1 .  I don't have any insight as to what might be causing the error.  You could, however, rule out the JIM software (if you wanted).  I see you're on 2.4.0.  I'm running 2.2.0.  Maybe you could down-grade (?) to 2.3 or 2.2 and see if the error goes away?  Just a thought....no idea if it's worth messing with since you mentioned it's all working.  Good luck. 


thanks @steve_summers .

I'm a bit hesitant to take that action.  It turns out my cloud instance was upgrade to 10.45 over the weekend and the issue started right during the middle of the upgrade window published by Jamf.  Entirely possible thats a coincidence, but when I noticed that the first thing I did was open a support ticket with Jamf, in case something went sideways.

thanks @steve_summers .

I'm a bit hesitant to take that action.  It turns out my cloud instance was upgrade to 10.45 over the weekend and the issue started right during the middle of the upgrade window published by Jamf.  Entirely possible thats a coincidence, but when I noticed that the first thing I did was open a support ticket with Jamf, in case something went sideways.


I had this problem a while back. It continued to work until we transitioned to Azure SSO. You may need to clone your current config and republish it. 

Still not clear on the underlying cause, but based on advice from Jamf support I re-ran the JIM 2.4 installer, selecting Modify, which cleared up the issue.  Jamf support indicated, without explanation, that there were errors in the JIM log relating to certificates used by the JIM, and re-running the installer would refresh the certs.  Which it appears it did, as the issue is now gone.

Still not clear on the underlying cause, but based on advice from Jamf support I re-ran the JIM 2.4 installer, selecting Modify, which cleared up the issue.  Jamf support indicated, without explanation, that there were errors in the JIM log relating to certificates used by the JIM, and re-running the installer would refresh the certs.  Which it appears it did, as the issue is now gone.


Confirm that this worked. Thank you for an accurate problem description, error message, and supporting log
Made this a quick 5 minute fix for me

Fyi, in my case I had to upgrade the version of JIM, run the .msi a second time, and then I was able to hit modify. Also, be mindful that the "Jamf Pro User Account" is the account you created in Jamf for the JIM connection. Other than that it worked perfectly. Thank you @pbenware1 for the solution. These are the solutions that should be written in Jamf's KB site.

Still not clear on the underlying cause, but based on advice from Jamf support I re-ran the JIM 2.4 installer, selecting Modify, which cleared up the issue.  Jamf support indicated, without explanation, that there were errors in the JIM log relating to certificates used by the JIM, and re-running the installer would refresh the certs.  Which it appears it did, as the issue is now gone.


I recently ran into the same issue with both my Dev and Production instances, and while I also believe it's a certificate expiration issue the time between the previous JIM enrollment and the occurrence of the InvalidDeviceSignature was not the same for both instances which seems odd.

I did create a support case complaining that if a JIM connection requires periodic cert renewal there should be a different notification in the Jamf Pro console than the basic "JIM heartbeat wasn't received" message. Especially given that LDAP queries appeared to continue to work (although it may only have worked for cached IDs). Jamf Support didn't indicate when that might happen, but they did refer to the FR covering this: https://ideas.jamf.com/ideas/JN-I-26995 I'm thinking it needs a whole lot more than the 4 votes it currently has.

Modifying the existing install worked for me as well - thanks!

So, a year and 3 weeks later, the same issue occurred again, with the same underlying cause:

java.security.cert.CertificateExpiredException: NotAfter: Mon Apr 29 14:22:22 UTC 2024

Same process to resolve it;

Stop the JIM service, reinstall, selecting "modify", reboot and its working again.

 

So, a year and 3 weeks later, the same issue occurred again, with the same underlying cause:

java.security.cert.CertificateExpiredException: NotAfter: Mon Apr 29 14:22:22 UTC 2024

Same process to resolve it;

Stop the JIM service, reinstall, selecting "modify", reboot and its working again.

 


There is a known bug associated with this issue as well:

PI111998: "Issued device certificate for Jamf Infrastructure Manager not automatically renewed following a renewal of the JSS built-in CA"

Ran the modify on the JIM installer and was able to get it connected back up.  This solutions is still relevant!

Just had this happen to me. It randomly stopped checking in, and no error in the logs about the java.security.cert either. But, this solved it, thank you.

Reply


Terms & ConditionsCookie settings