Hey folks, hoping someone can shed some light on this headache we're having. Our XGS firewalls are supposed to auto-renew their device certificates via Central, but the process just... stopped working on a few of them last cycle. No warning in Central, and we only caught it because of a spike in user complaints about the captive portal warning looking super scary!
Now we're stuck manually generating CSRs, getting them signed, and uploading the certs the old-fashioned way for each box. It's a real pain, especially with remote sites. Feels like a step back into the dark ages.
Has anyone else run into this? We're on the latest firmware sync with Central, and our NTP is spot on. I'm wondering if it's something in the chain of trust that got borked, or maybe a specific setting in Central that got flipped without us noticing. Our renewal window was definitely still valid.
Would love to hear if you've found a fix or a smoother workaround. Cheers!
Your situation mirrors an issue we documented extensively after our last renewal cycle. The auto-renewal failure on a subset of devices, despite correct NTP and firmware, often traces back to a specific certificate template policy applied in Central that the device can't fulfill. In our case, it was the "Enhanced Key Usage" attribute; the auto-renewal process silently choked when the defined template required an OID the device's internal CA couldn't satisfy.
Check the Certificate Authority configuration linked to your device profile in Central. Focus on the template details. A temporary workaround that saved us for a few stubborn nodes was to temporarily revert the policy to a basic template, force a manual sync, allow a renewal cycle to pass, then re-apply the intended template. It's inelegant, but it prevented a full manual recertification of all affected units.
Have you isolated whether the failed devices share a particular configuration profile or site tag that others, which renewed successfully, do not?
Check the SLA.
That's a really sharp observation about the certificate template policy. It's the kind of silent failure that's so easy to miss until it's too late.
Your temporary workaround is clever, though I worry about the timing on a large scale. If you revert to a basic template and force a sync, how long did you typically have to wait before the auto-renewal actually triggered and succeeded? Was it immediate after the sync, or did you have to wait for the next scheduled check-in?
That's a great question about timing. In our experience, triggering a manual sync from the device to Central after the policy change didn't *immediately* start the renewal. The renewal process itself seemed to run on a separate, internal schedule, maybe once a day.
So we'd revert the template, force the sync, and then just had to wait. It often took a few hours for the new certificate to show up. The annoying part was having no real status indicator; we just kept checking until the old cert's expiration date updated.
This lag is exactly why scaling that workaround feels risky. You're left in the dark, hoping it takes before the old one fully expires. Not ideal for a critical network service.
Keep it civil, keep it real.
Exactly. That's the core operational flaw. The process is opaque and doesn't respect the manual sync as a trigger event.
I've found you can sometimes force the renewal check by bouncing the device management service via CLI after the policy change and sync. But it's still a roll of the dice. The real problem is the lack of a true status or force-renew command.
This is why we built external monitoring for cert expiration dates on all our edge devices. You can't trust the built-in process to fail visibly.