About SCEP certificate renewal

Renewal is the workflow where a Simple Certificate Enrollment Protocol (SCEP) client enrolls a new key using the same Subject as the certificate it already holds. Because the client proves its identity with the certificate it is replacing, it does not need a challenge password to renew.

Trust Protection Foundation accepts renewal requests in two forms:

• A RenewalReq message, the dedicated renewal message type defined in RFC 8894.

• A PKCSReq message, the renewal flow defined in the earlier Nourse draft.

A single Trust Protection Foundation SCEP server handles both forms automatically, so a device that does not implement RenewalReq can still renew. RenewalReq is not mandatory to implement in the RFC, so not every SCEP client offers it.

A client can discover that renewal is available by sending a GetCACaps request. Trust Protection Foundation advertises Renewal in the response.

How a renewal differs from an enrollment

A renewal is very similar to a SCEP enrollment. There are two key differences:

• The client signs the request with its current certificate, which proves possession of that certificate's private key. This signature is what authenticates the request.

• The challenge password becomes optional. Because the signature already establishes the client's identity, requiring a challenge password on renewal adds no security, and distributing one to devices that already hold a valid certificate is discouraged.

Requirements that Trust Protection Foundation enforces

The signature proves that the request is authentic, but Trust Protection Foundation applies several more checks before it allows the renewal. These checks prevent a client from using a renewal to obtain a certificate it would not be entitled to enroll. A renewal request is rejected unless all of the following are true:

• The certificate is already managed by Trust Protection Foundation.

• The certificate was originally enrolled through SCEP. A SCEP client cannot take ownership of a certificate that Trust Protection Foundation acquired any other way, such as through a discovery scan, an import, or a different enrollment method. This restriction applies both to a renewal and to a request that the Match X.509 Subject to existing certificate object rule matches to an existing Certificate object. When Trust Protection Foundation refuses a request for this reason, it writes this log message:

  Network Device Enrollment - Cross-Source Issuance Denied

• The certificate is not governed by Microsoft Intune, or the request carries an Intune challenge that Intune validates. A certificate enrolled through Intune can only ever be renewed through Intune, which prevents a device whose private key is compromised from renewing without Intune's consent.

• The Subject name of the new certificate is unchanged.

• The Subject Alternative Names (SANs) are unchanged or narrowed. A renewal can drop SANs, but it cannot add one, because adding a SAN would let a client use a renewal to widen the set of identities its certificate asserts. Adding a SAN makes the request a new certificate, which the client must enroll with a PKCSReq message instead.

• The signing certificate—that is, the certificate the client currently holds—is valid: not expired, not revoked, and not disabled in Trust Protection Foundation.

• The renewal does not move the certificate to a CA template that your configuration does not call for. A client cannot change the CA template its certificate is issued from simply by renewing at a different SCEP URL. See "Changing the issuing CA during renewal."

What happens when no renewal candidate is found

The two request types behave differently when Trust Protection Foundation cannot match the request to a certificate that meets all of the requirements above. The difference matters when you are troubleshooting a device that unexpectedly received a brand new certificate instead of a renewed one.

• RenewalReq is deterministic. If no suitable renewal candidate is found, the request fails. Trust Protection Foundation does not fall back to enrolling a new certificate, even when the client supplies a valid challenge password.

• PKCSReq may be interpreted as a renewal. Because the Nourse-draft renewal reuses the enrollment message type, Trust Protection Foundation infers the renewal from the contents of the request rather than from the message type alone. If no suitable renewal candidate is found but the request meets the ordinary enrollment requirements—which includes supplying the challenge password—Trust Protection Foundation enrolls a new certificate instead.

If you would rather a failed renewal be reported as a failure than silently become an enrollment, use a client that sends RenewalReq.

Where the renewed certificate is stored

A renewal never moves the Certificate object. When Trust Protection Foundation matches a renewal request to a managed Certificate object, it associates the new Certificate Signing Request (CSR) and certificate with that object in the folder where the object already resides, regardless of how the rules on the Network Device Enrollment Rules tab are configured. Trust Protection Foundation consults those rules during a renewal only to work out which folder a new enrollment would have gone to. It uses that folder to choose between several Certificate objects that hold the same certificate, and to decide whether a challenge password authorizes a change of CA template, as described in "Changing the issuing CA during renewal."

For how rules apply to a new enrollment, see Example of rule execution.

Changing the issuing CA during renewal

Every SCEP request, including a renewal, is enrolled against the CA template configured for the SCEP URL that the request is sent to:

• A request sent to the base SCEP URL uses the Default Certificate Authority in the default NDE settings on the root Platforms tree.

• A request whose URL includes a CA Ident string uses the Certificate Authority setting of the Policy object that defines that CA Ident. See Using a policy to configure NDE.

• A request whose URL includes a CA Ident string that no Policy object defines does not fail. Trust Protection Foundation falls back to the default NDE settings, including their CA template, challenge password, Intune, and placement settings.

So a renewal is not tied to the CA template the certificate was issued from. If the URL's CA template is different, renewing changes the certificate's CA template. A change in the issuing CA template is allowed when the Policy object or NDE settings that apply to the certificate's folder have been modified to specify a different CA template, or when the SCEP request carries the appropriate challenge password.

The Policy object or NDE settings that apply to a folder are:

• The closest Policy object at or above the folder that defines a CA Ident, if there is one.

• Otherwise, the default NDE settings, but only if the folder is the Default Certificate Container or a folder below it. If no Policy object defines a CA Ident, or Support additional CAs configured on policies is turned off, the default NDE settings apply to every folder.

A challenge password is the appropriate one when it would enroll a new certificate into the folder that holds the Certificate object. It carries the same authority as a new enrollment into that folder.

When the CA template changes, Trust Protection Foundation writes an informational log message to record the change:

Network Device Enrollment - Certificate Authority Changed

In any other case, Trust Protection Foundation refuses the renewal and writes a log message that names the certificates that could not move:

Network Device Enrollment - CA Template Change Refused

A client cannot move its certificate to a different CA template by sending a different CA Ident string. The certificate the client signs with proves which device it is, not which CA template it is entitled to, so a move of that kind needs a challenge password. With a PKCSReq message, a valid challenge password that places the request in a different folder enrolls a new certificate in that folder instead of renewing the existing one, as described in "What happens when no renewal candidate is found."

To move a fleet of devices to a new CA template without re-enrolling them:

1. Change the CA template that the devices' SCEP URL uses: the Certificate Authority setting on the Policy object that defines their CA Ident, or the Default Certificate Authority in the default NDE settings.

2. Recycle the SCEP application pool so that the change takes effect.

Each device moves to the new CA template the next time it renews, provided those settings apply to the folder that holds its certificate. Watch for the Certificate Authority Changed message to confirm which certificates moved, and for CA Template Change Refused to find the devices that could not.