While Hiro is busy abusing that company with their own code-signing certificate, they opened a support call with Microsoft for a whole different issue. Turns out, their Intune managed devices can no longer connect to the corporate WiFi, which is affecting doctors in their treatment of patients.

Oops.

The support engineer on the Intune case quickly points to SCEP as the issue. Hours later, they finally get to an NDES specialist who points to the two service certificates as the culprits. They expired a few days ago and folks only noticed when devices finally gave up trying to get new certificates.

A couple of renewals later, all is well in the world again. Well, all is well until Hiro figures out his game.

What just happened

NDES (Network Device Enrollment Service) is the SCEP server. SCEP is how devices without directory credentials enroll for certificates. Every device that doesn't join the domain — mobile devices, IoT, network gear, anything Intune-managed — uses SCEP to ask for a certificate.

NDES sits between the device and the certification authority. The device sends an encrypted enrollment request to NDES. NDES holds two special certificates, called registration-authority certificates, that let it decrypt the device's request and re-sign it on the device's behalf so the CA trusts the request.

Those two certificates are:

  1. CEP Encryption certificate — decrypts the incoming enrollment requests from clients
  2. Exchange Enrollment Agent Offline request certificate — co-signs the requests to the CA on behalf of the client

Both of these are regular certificates. They have expiration dates. When they expire, NDES can't decrypt incoming requests and can't sign outgoing ones. Enrollment stops. Devices can't get certificates. WiFi, which relies on certificate-based authentication, stops working.

The incident response found both certificates had expired three days prior. They'd been issued two years ago when the role was deployed. The default validity period on those templates is two years — long enough that expiration vanishes from institutional memory. Nobody was monitoring them. Nobody was set up to replace them before they expired.

Why the defaults don't auto-renew

Microsoft's out-of-the-box NDES templates for these two certificates are hardcoded into the deployment. You cannot replace them until AFTER NDES is deployed. The service launches with the defaults, uses the defaults, and they don't auto-enroll. The assumption is that an operator will manually renew them when they're about to expire.

That assumption breaks in practice.

In most organizations, NDES gets deployed, it works, and then it disappears from the monitoring queue. The service account running it is a gMSA with minimal privileges. The certificates live in the machine's certificate store — which is exactly where they shouldn't be. Ideally, the NDES service certificates would be HSM-backed, stored in a hardware security module that doesn't allow export and limits access to the private keys. In practice, they sit in the machine store like any other certificate, accessible to anyone who compromises that server.

Years pass. The people who deployed NDES have moved on. The certificates expire in the middle of the night. The service keeps running but can't do its job. Devices retry enrollment, fail, and gradually give up. By the time someone notices, WiFi is broken, doctors are affected, and incident response is paging people at 3 AM.

The fix: duplicate one, replace the other with auto-renewal

The solution requires understanding the constraint: the CEP Encryption certificate is a machine certificate and can be duplicated. The Exchange Enrollment Agent Offline request is a user certificate and cannot auto-renew on a computer, no matter what you do to the template.

The actual fix:

  1. Duplicate the CEP Encryption template into a custom template.
  2. For the Exchange Enrollment Agent, don't duplicate the default. Replace it with the Computer Enrollment Agent template, which is already machine-based and can auto-renew.
  3. Enable auto-renewal on both the duplicated CEP Encryption template and the Computer Enrollment Agent template.
  4. Grant the NDES server (computer object) Enroll and AutoEnroll permissions on both templates, with Use existing subject value and Valid existing cert configured.
  5. Grant the NDES gMSA private key access to both enrolled certificates.
  6. That's it. NDES automatically discovers and uses the new certificates.

The "Use existing subject value" setting ensures the NDES server re-enrolls using the same subject name as the existing certificate, maintaining the service's identity across renewal cycles. The "Valid existing cert" condition requires that a valid certificate already exists before renewal can proceed — this prevents enrollment gaps during the renewal process.

NDES selects which certificates to use based on three criteria: they must have the correct EKU, they must have the same subject values that were configured during the original NDES deployment, and it uses the ones with the longest expiration date. No registry configuration required. The service finds them on its own.

Once this is set up, the NDES server will automatically re-enroll both certificates before they expire. The machine context handles re-enrollment. The template restamps private-key access to the gMSA on each renewal, so the service account maintains access to the private keys even as the certificates are replaced.

The renewed certificates are adopted by the running service automatically. No service restart required. No manual intervention required. The certificates renew, the service keeps running, and the incident that just broke WiFi never happens again.

The field reality

This is the single most common support call for NDES deployments. Not a misconfiguration of the protocol. Not an attack. Not a design flaw in SCEP. Just: "the certificates expired and we didn't notice."

The fix is one-time. Setup takes maybe an hour once you know what you're doing. After that, it's done. The certificates renew themselves for the lifetime of the service. The only time you'll touch them again is if you decommission the role.

What to check this week

If you have NDES deployed, check the expiration dates on both certificates right now:

  • Look at Certificates > Personal in the machine store on your NDES server
  • Find the CEP Encryption certificate and the Exchange Enrollment Agent Offline request certificate
  • Note their expiration dates
  • If either is within 30 days of expiration, renew them today
  • If you haven't already, implement auto-renewal

The steps:

  1. Duplicate the CEP Encryption default template in Active Directory
  2. Identify the Computer Enrollment Agent template (this replaces the default Exchange Enrollment Agent)
  3. Enable auto-enrollment on both the duplicated CEP Encryption template and the Computer Enrollment Agent template
  4. Configure both templates with "Use existing subject value" and "Valid existing cert" settings
  5. Grant the NDES server (computer object) Enroll and AutoEnroll permissions on both templates
  6. Enroll both certificates on the NDES server
  7. Grant the NDES gMSA private key access to both enrolled certificates
  8. Verify both certificates auto-renew before their expiration dates

NDES will automatically use the new certificates based on EKU and expiration date. No configuration required.

This is not complicated. It's not clever. It's just: set it up once, and it works forever.

Most organizations that run into this problem discover it the hard way — like the one in this story, simultaneously being compromised in three different ways at once. At least one of those compromises could have been prevented with an hour of setup work.

And if you want to close the door completely: those NDES service certificates should be HSM-backed, not sitting in the machine store. But that's a conversation for another article.