CA Certificates and APN Feedback Error

[ACurnow_LU]

Hi all,

I'm not sure if this has been posted about beforehand, though I couldn't really find anything that answers my question beyond "Re-enroll the device".

Basically we had a mishap in our environment where, upon renewing our Push Certificate, another Apple ID than the original was used, causing our devices to display the "APNs Feedback error". From preliminary research it seemed that this was a known issue, but no fix in place beyond re-enrolling the affected devices (All of them, if that's the case).
We have since found that going back to the original Apple ID and generating the Push Certificate from there has reverted the majority of our devices, which we hadn't yet re-enrolled, to having no feedback errors, but those we had already rolled this out for are now getting the APNs Feedback error.

My question is, to avoid re-enrolling each device (Which doesn't seem to be able to be automated, even by using sudo jamf reenroll -invitiation ${invitationID} as this seems to break halfway through and leave us with a device that can't communicate with our JSS), is it possible to simply replace the CA Certificate under Profiles downloaded by Jamf during enrollment with the updated one from the JSS?
My main concern would be that that would have some sort of back-end domino effect which wouldn't be realised at first, but could potentially cause more harm than good.
To extend on this: Has anyone discovered a better way of determining which devices are experiencing said APNs Feedback error through Extension Attributes, perhaps?

If anyone has any input on this, it would be greatly appreciated! Thank you.

[ACurnow_LU · Accepted solution]

In case anyone else runs into this problem in future and happens onto this thread:
We were able to figure this out in the end by enabling remote management on each machine using the below script (Thanks to @tuinte on this thread):

#!/bin/sh
# Declare global variables to improve readability.
kickstart="/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart"
privs="-all"
targetUser="adminuser"

# Add targetUser to SSH Access user group.
dseditgroup -o edit -a "${targetUser}" -t user com.apple.access_ssh
# Set Remote Login to On, in case this is set to Off on the local machine.
/usr/sbin/systemsetup -f -setremotelogin on
# Enable kickstart and configure for targetUser to be granted all privileges, then restart the agent to apply changes.
"${kickstart}" -activate -configure -allowAccessFor -specifiedUsers
"${kickstart}" -configure -access -on -privs "${privs}" -users "${targetUser}" -clientopts -setmenuextra -menuextra yes
"${kickstart}" -restart -agent

From there, we were able to run sudo jamf reenroll -prompt and run with our JAMF credentials and the local admin credentials.
Note that at this stage, the user will need to approve the MDM profile before it is fully implemented on the target machine. We found it easier for a prompt to appear via jamfhelper for UX reasons, using the below script:

#!/bin/sh
# Declare Global Functions
message(){
  # Define local variables.
  local message="${1}"
  local title='IT Support'
  local jamfHelper='/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper'
  local iconPath='/path/to/icon.png'

  # Data Validation
  [[ -z "${message}" ]] && message='Press OK to continue'

  # Display dialog box message if application is running, otherwise continue silently.
  if [[ -e "${jamfHelper}" ]]; then
    if ! "${jamfHelper}" 
    -windowType hud 
    -title "${title}" 
    -heading "MDM Approval" 
    -icon "${iconPath}" 
    -button1 'OK' 
    -description "${message}" 
    -defaultButton 1 
    -lockHUD &>/dev/null
    then
      printf '%s
' "${cancelMessage}" 1>&2
      exit 1
    fi
  fi
}

function sendToLog (){
  printf '%s
' "${1}"
}

# Main function to perform
message "In order to maintain security configurations, your device has been re-enrolled in JAMF and you will be required to manually approve the MDM profile - Please do so by following these steps:
1 - Select MDM Profile on the left-hand side.
2 - Click Approve under the profile title.
3 - Close out of the System Preferences window once complete.

If you encounter any issues, please contact IT through the preferred channels."

sendToLog "Opening Profiles pane in System Preferences."
open -b com.apple.systempreferences /System/Library/PreferencePanes/Profiles.prefPane

sendToLog "Sleeping for 30 seconds and then checking and updating records on JAMF."
sleep 30
sendToLog `sudo jamf recon`

exit 0

Once the user has approved the MDM Profile, we can check this in JAMF under the User Approved MDM tag. We also used this tag to automate the second part of the process so any devices we have where User Approved MDM is No, they receive the above prompt.

From what we've seen, this has sorted our issue, but there's still the manual effort behind remoting into each device and running the above commands. If anyone has any clue as to why the sudo jamf reenroll -invitation ${invitiationID} wouldn't work and instead stalls, I'd greatly appreciate the feedback!

[mpenrod]

**Never mind - it opened for me after I clicked "OK"

Script seems to work except for it can't open System Prefs??? Script exit code: 0
Script result: Opening Profiles pane in System Preferences.
LSOpenURLsWithRole() failed for the application /Applications/System Preferences.app with error -10810 for the file /System/Library/PreferencePanes/Profiles.prefPane.

[Ke_ReM]

@ACurnow_LU 
Thanks for sharing this solution. I just had this mishap where I used trhe wrong ID for the first time.
I have since uploaded the newly generated APN with the incorrect ID back to our JSS and am wondering now (since I now know the correct ID and have access to the APN portal) how to go about reverting this before we hit the APNs error that you saw (its only been 4 days since expiry).
The macOS environment seems okay for now but the iOS devices are already starting to hang when I try and download anything via Self Service app. Thje topic ID is definitely different so thats confirmed.

From what you have written, you say to go and just generate it using the correct ID but it is asking for a Vendor signed CSR file which I believe you get from the JSS (which now has the incorrect ID APN).

SHould I just go through the process anyway and hope the original ID created APN prevents the need to reenroll our devices again?

[ACurnow_LU]

Hey @Ke_ReM, while for us we went ahead with swapping the certificate and re-enrolling our devices, I believe if you generate the APN Cert using the original ID, you shouldn't need to do so.

The Vendor-signed CSR file is the same either way as far as Apple's concerned, it just needs to know which Vendor is looking to make use of their APN service.

[Ke_ReM]

Yep can confirm, I bit the bullet last night and went ahead and renewed the APN in our JSS regardless of the fact I had already renewed it with an incorrect ID as I knew time was critical and ticking.

It basically overwites and the Topic ID's become the same as they were originally which means the existing managed devices are recognised and do not need to be re-enrolled.
Happy days.