802.1x certs not renewing

Turns out the -verbose argument on the profiles command was causing some of the problems, but it still won't renew.

My initial test Mac did eventually renew with about 5 days to go before it completely expired. That is cutting it too close for comfort if you ask me. I have another bunch of test Macs about to expire in a week and none of them have renewed yet.  According to Apple's documentation, they should start attempting to renew at 14 days before expiration, but I'm not seeing that happen at all. These Macs are mostly running Monterey with I think 1 or 2 running Ventura. Does anyone have any tips for either forcing them to renew or at least point me to the log that will tell me why they aren't renewing?

Out of curiosity, did your Macs renew? Also, what CA are you utilizing?

Our Macs are automatically renewing now on day 9 or 10 before expiration. So far they've all been successful when they cross that threshold and are online. We're using an internal CA, but from what I can tell there is nothing on the CA that is restricting it to the 9 or 10 day limit.

Out of interest, there is a renew option built into the SCEP payload, is that not an option for some reason for you?

This seems to relate to what we're currently seeing. We are coming up on a year of rolling out EAP-TLS for Apple devices. We're issuing 802.1x machine certificates via SCEP, from a FOSS NAC solution called PacketFence. PacketFence is the SCEP server and the CA for Apple devices. Jamf is configured as a SCEP proxy for PacketFence. We're using Entra's Application Proxy so SCEP certs can be issue regardless of where devices are.

In our config profile, we have 'Redistribute Profile' set to 15 days. However, I'm not seeing any devices renewing their certs yet. I know of at least one that is 8 days away from expiry currently.

When I ran the command sudo profiles renew -type configuration -identifier [PROFILE-IDENTIFIER-STRING] on two computers, both with profiles expiring ~13 days, it caused both of them to install a new cert, with a matching CN as the one that was getting close to expire. I look in PacketFence, which shows the updated expiration dates as well.

So it seems like manually triggering the renewal works fine. So renewing the cert via SCEP *is* working. It's just not happening automatically, at the 15 day mark, like it should.

Any thoughts? I've reached out to the respective parties support and am waiting to hear back. All macOS are on Sequoia. I know of at least one iPad that is ~11 days from expiration, so it doesn't appear to be only macOS. Jamf does show the SCEP certs as 'Expiring' when viewing the inventory record for a device, in the 'Certificate' section.

I was also wondering if the OP was dealing with SCEP certs or not. Because Apple's documentation says that /Library/Preferences/com.apple.mdmclient AutoRenewCertificatesEnabled has no bearing or impact on SCEP certs. Also - "The following certificates are not eligible and must be renewed manually: Certificates delivered as part of an SCEP payload of any kind." In my case, Jamf is a SCEP proxy, so Jamf should be monitoring and renewing the certs.

Our new Jamf enrollments grab SCEP certs and join the 802.1x WiFi with no issues. It's this automatic renewal mechanic I'm concerned about.

Edit: So the main issue here ended up being that PacketFence's SCEP certificate template (as we're using it for PKI) had the Organisation field filled out, and it was overwriting the O=$PROFILE_IDENTIFIER that Jamf was adding, when Jamf would go out to PacketFence to SCEP a cert on a devices behalf (as it's acting as a SCEP proxy). Therefore, all of the SCEP certs that were getting installed on devices no longer had the O=$PROFILE_IDENTIFIER, so Jamf couldn't match expiring certificates to their parent config profile, which it needs to be able to do for the automatic profile renewal process to work. After I cleared out the Organisation field in the PacketFence SCEP cert template, and removed and re-pushed the profile on a test device, I observed the $PROFILE_IDENTIFIER being preserved and showing up for the first time in the certificate subject of the SCEP cert on the test device.

For this test, I also changed the validity period  in the cert template to 14 days. Over this past weekend, I noticed Jamf had successfully renewed the profile and cert on the test device. First time I've seen this happen successfully.

Per this article: https://learn.jamf.com/en-US/bundle/technical-paper-digicert-current/page/Distributing_Certificates_Using_the_SCEP_Protocol.html

Specifically: 'Note: Configuring this option adds "$PROFILE_IDENTIFIER" to the Subject field, which is limited to 64 characters by the x.509 cryptography standard. If the Subject field exceeds 64 characters, certificates will fail to renew. For example, the profile identifier may be up to 36 characters, and if you also use a payload variable such as $USERNAME or $EMAIL with around 29 characters, you will exceed the 64-character limit.'

Our cert subject is 80+ characters and the renewal is still working. This might be because PacketFence is more lenient on the limit, I'm not quite sure. I think I'm still going to shorten the CN's to stay within that 64-character length, just in case.

So on paper, we had two issues ($PROFILE_IDENTIFIER not existing in the SCEP cert subject, and exceeding the 64 character cert subject limit), but only the former was actually preventing Jamf's certificate renewal process to happen.

Another interesting (to me) observation is that when you run a sudo profiles renew -type configuration -identifier [Profile Identifier] - the computer installs a new cert with the same CN as the one that was expiring. So you have two now with the same CN.

When Jamf's automatic renewal process occurs, it keeps the original cert, but just refreshes it. Almost a little cleaner.

So we now have the automatic renewal process working and it appears to be renewing right around that ~14 day mark.

Troubleshooting 802.1x Certificate Auto Renewal in Jamf Pro:

It sounds like you're facing a critical issue with certificate renewal for your 802.1x WiFi authentication. Let's systematically troubleshoot this problem.

Check the below Items:

• You deployed 802.1x WiFi auth using non-AD certificates

• Set AutoRenewCertificatesEnabled to YES

• Certificates are approaching 1-year expiration (first on Feb 9)

• Automatic renewal isn't occurring as expected

• Manual renewal attempts are failing

1. Verify Auto-Renewal Configuration

# Check current setting
sudo defaults read /Library/Preferences/com.apple.mdmclient AutoRenewCertificatesEnabled

# Verify MDM can manage certificates
sudo profiles show -type enrollment

(Should show "This Mac is enrolled via DEP" and MDM capabilities including certificate management)

2. Check Certificate Validity Period

# List all certificates
security find-identity -v -p 802.1X

# Check specific certificate details
security find-certificate -a -c "YOUR_CERT_NAME" -Z | grep -i "valid"

3. Correct Manual Renewal Command

The error suggests syntax issues. Try:

sudo profiles renew -type configuration -identifier "CORRECT-PROFILE-IDENTIFIER-STRING"

(Remove the -verbose flag which seems to be causing parsing issues)

4. Force MDM Check-in

sudo jamf manage
sudo jamf recon

Common Troubleshooting Steps:

1. MDM Profile Issues

   • Reinstall the MDM profile: sudo profiles renew -type enrollment

   • Check MDM logs: sudo log stream --predicate 'subsystem == "com.apple.ManagedClient"'

2. Certificate Authority Problems

   • Verify your SCEP/CA server is reachable

   • Check for updated root/intermediate certificates

3. Profile Configuration

   • The 802.1x profile may need to be updated to reference a new certificate

   • Check if the profile allows for renewal (some require manual approval)

4. System Time Issues

   • Verify system time is correct: ntpdate -u time.apple.com

Workaround:

For devices nearing expiration

1. Create a new configuration profile with updated certificates

2. Scope it to affected devices

3. Push via Jamf with highest priority

Permanent Solution:

1. Test with a new profile on non-critical devices

2. Monitor renewal attempts:

    

   log stream --predicate 'eventMessage contains "certificate"'

3. Consider using Jamf Connect for more reliable certificate management if this continues to be problematic

# Check current setting
sudo defaults read /Library/Preferences/com.apple.mdmclient AutoRenewCertificatesEnabled

# Verify MDM can manage certificates
sudo profiles show -type enrollment

# List all certificates
security find-identity -v -p 802.1X

# Check specific certificate details
security find-certificate -a -c "YOUR_CERT_NAME" -Z | grep -i "valid"

sudo profiles renew -type configuration -identifier "CORRECT-PROFILE-IDENTIFIER-STRING"

sudo jamf manage
sudo jamf recon

@alpaul Respectfully, please don't copy and paste answers from ChatGPT, which this very clearly is.

Your response is littered with errors and things that don't make sense.

Not just me then..