802.1x certs not renewing

[AVmcclint]

Almost a year ago we implemented 802.1x wifi authentication NOT using Active Directory certs. The certificates all issue properly and work just fine with our WiFi authentication.

After we deployed the profiles and issued certs, I made sure this was set:

sudo defaults write /Library/Preferences/com.apple.mdmclient AutoRenewCertificatesEnabled -bool YES

Now that we are approaching the 1 year expiration of some of the first Macs to test this, we are expecting their certs to automatically renew, but they are not. I have a Mac with a computer cert expiration of Feb 9 - well within the default 14 day window for renewing - but it isn't renewing. Keychain Access still indicates that it expires Feb 9. There are no duplicate certs that would indicate a renewal. The Profiles system preferences does not have a renew or update button for the 802.1x profile. Here is what happens when I try to renew it manually with the profiles command:

profiles -verbose renew -type configuration -identifier CORRECT-PROFILE-IDENTIFIER-STRING

profiles: verbose mode ON
profiles: invalid option -- b
profiles: error: unknown argument passed in
fail
profiles: invalid option -- t
profiles: error: unknown argument passed in
fail
profiles: invalid option -- y
profiles: error: unknown argument passed in
fail
profiles: invalid option -- n
profiles: error: unknown argument passed in
fail
profiles: invalid option -- t
profiles: error: unknown argument passed in
fail
Error: You must provide an action. Use 'profiles help' for help, or use the man page.
profiles: returned error: 6
fail

I've looked through the man and help page but I cannot figure this out.  The earliest cert expiration is Feb 9, with a handful of testers shortly after that, then the general population. I'm running out of time. Does anyone have any tips on figuring this out?

[AVmcclint]

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

% sudo profiles renew -type configuration -identifier CORRECT-PROFILE-IDENTIFIER-STRING 
Password:
{
    Changes =     (
    );
}
certificate renewal for profile: 'CORRECT-PROFILE-IDENTIFIER-STRING' returned 0 ((null))

[AVmcclint]

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?

[mike_blasberg]

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

[AVmcclint]

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.

[charliwest]

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

[whiteb]

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_...

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.