This blog will be about me looking at the Intune Device Certificate renewal process and what happens behind the curtains

1. Introduction

I guess we all know by now that the Intune MDM device certificate needs to be renewed each year. Without it, the device stops communicating with Intune, and everything will be broken!

Without the possibility of communicating, all sorts of important Intune stuff will stop working, and it’s up to you to fix it. Luckily, I already have some blogs that tell you how to solve it.

Intune | MDM-only | Enrollment | Missing Device Certificate (call4cloud.nl)

While writing those blogs, I was wondering how the Intune Device certificate was automatically renewed each year. I guess this blog will take you down the renewal rabbit hole.

2. Renewal Flow

When the Intune MDM device certificate needs to be renewed a nice scheduled task named “Schedule created by enrollment client for renewal of certificate warning” is given the power to perform this sometimes difficult task on the client side.

As shown above, we noticed that there is a nice task responsible for the Intune Certificate Renewal process. This scheduled task is configured to be run every 7 days during 49 days

This task is configured to run 41 days BEFORE (RenewalPeriod) the Intune Device certificate will expire. (More on this amount of days later on)

If the device’s current time is in the expected renewal time and we are manually launching this scheduled task, we will notice it will use the deviceenroller.exe process with the /c /r /d parameters to start the renewal process. I assume the /r stands for renewal…

Like always it will try to first discover the Enrollment URI by sending out a discovery request to enrollment.manage.microsoft.com

If the device has found the appropriate enrollment URLs, it will send a request to fetch the proper Enrollment Policy and validate the renewal request.

If the device successfully retrieved the Enrollment policy, it will reach out again to https://fef.amsub0302.manage.microsoft.com/StatelessEnrollmentService to start the Certificate Renewal by using the X.509v3 Token Enrollment Extensions protocol (WSTEP)

When we examine the request from above, we will notice that the device also sends the required “RequestType,” the “BinarySecurityToken,” and some “AdditionalContext” in the SOAP body of the renewal request.

Let’s begin with the easiest one, the ContextItems. As shown below, these ContextItems contain a lot of information about your device. I will explain later on why it also communicates this information to the enrollment service.

Now we have noticed that the request also contains some additional information about the device itself, let’s focus on the “BinarySecurityToken” a bit now.

The request contains a BinarySecurityToken in the SOAP body. This BinarySecurityToken is nothing more than your existing Microsoft Intune MDM Certificate. Let me show you how I came to that conclusion. In my first attempt, I tried to decode this Base64 value with the online tool that I know off

As shown above, it showed me a lot of scrambled stuff but also some lines mentioning the Microsoft Intune MDM Device CA. When noticing those lines, I was curious if I could decode and convert the BinarySecurityToken itself, to our Intune MDM Certificate. To do so I used this PowerShell script to create a nice new shiny certificate

$certBase64 = 'BinarySecurityTokenHere'
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]([System.Convert]::FromBase64String($certBase64))
$cert | Format-List *
$Base64Cert = @(
                '-----BEGIN CERTIFICATE-----'
                [System.Convert]::ToBase64String($Cert.RawData, "InsertLineBreaks")
                '-----END CERTIFICATE-----'
            )
$Base64Cert | Out-File -FilePath c:\install\mdmcert.cer -Encoding ascii -Verbose:$VerbosePreference

As shown above, when converting that BinarySecurityToken we will get back our Intune Device Certificate. Let’s continue this wonderful story!

After the enrollment service receives the renewal request with all that information in it, the web service will check

• if the signature of the BinarySecurityToken is correct.
• If the request contained the Intune Device Certificate (BinarySecurityToken)
• If the device is in the renewal period (RenewalPeriod)
• If the request came from the same device as the original request for initial enrollment (AdditionalContext.. sounds familiar right?)

If everything checks out and of course, only if the certificate is eligible for renewal will it send out a nice new Security Token with the NEW Intune MDM certificate in it. Yes…. you read it correctly, NOT a renewed certificate but a new Intune Device Certificate!

Of course, when the device is not eligible for renewal (determined by the enrollment service) you will receive the: NotEligbleToRenew error.

Let’s focus a bit more on that “NotEligbleToRenew‘ part because I guess we all want to know when the device is eligible to renew its certificate, right? Okay Okay…it’s more like a certificate replacement as you ask me but who is asking?

The automatic certificate renewal (RenewRoboSupport | request on behalf of ) will try to renew the certificate every 7 days (RetryInterval) for 41 days (RenewalPeriod) before the Intune MDM Certificate expires. You could check out yourself on the client by taking a look at the deviceenroller.exe or the registry.

3. Client Side

When taking a closer look at what is happening on the client side we need to open DeviceEnroller.exe with the IDA tool. After opening the deviceenroller.exe with IDA, I was first curious about what we could spot.

Let’s start to dig into the Scheduled task AKA CheckAndFixRenewSchedule and the /c /r /d deviceenroller.exe parameters we noticed earlier.

This CheckAndFixRenewScheduletask will call upon the deviceenroller.exe (ScheduleRenewalWork)

As shown below, we will notice that those deviceenroller.exe parameters are also mentioned in the ScheduleRenewalSession function.

After spending some more time with IDA and looking at the deviceenroller.exe process, I stumbled upon these functions and the registry keys they call upon.

• GetDeviceCertExpireTime
• IsLastRenewRecent

I noticed those 2 functions both call up on the “RegGetValue” function, which leads us to the well-known software\microsoft\enrollments registry key

As shown below, the Enrollments\GUID registry section also has the “RenewalPeriod” and “RenewTimeStamp” keys in it

After running the scheduled task to manually renew the Intune certificate, the event log will mention event 3000, which states that the “Current time is NOT earlier than expected renew attempt time, skip renew.“

So, I guess it’s pretty obvious that those keys (also mentioned in the CertifcateStore CSP) are used to determine on the client side whether the certificate is up for renewal. Let’s test it out, shall we?

4. Manipulating the settings

In the last part, I showed you which registry keys are used on the client side to determine if the certificate is up for renewal. Let’s find out if we can manipulate these keys on the client side to trigger the renewal or extend the “renewal period.” As mentioned earlier, when looking at the WSTEP protocol and the Certificate CSP, we will notice the same settings.

Okay, I guess we can configure a CSP to change these values? (or use the registry) but here it comes as, In Windows, the renewal period can ONLY be set during the MDM enrollment phase. How the hell do we set this during enrollment? Sounds like the chicken and egg discussion.

Of course, I tried to alter the “RenewalPeriod” registry key myself because when using the default value (41) I just got the message that the“Current time (2022-09-21T12:54:15) is earlier than the expected renew attempt time (2022-09-22T 2:59:06),

After playing around with it a bit more and trying out multiple values, I changed the RenewalPerdiod to 130. After changing it and running the scheduled task, I got another error mentioning that “MDM Enroll: Server Returned Fault/Code/Subcode/Value=(NotEligibleToRenew) Fault/Reason/Text=(NotEligibleToRenew).”

In addition to the enrollment server message mentioning that we aren’t Eligible to Renew, we will also notice that the error code has been changed to 0x80180016. When looking up this error code, we will see that it is nothing more than a code for mentioning the same message we got.

“The Server Rejected the request” , The server…..

While trying to manually renew the certificate with the changed “RenewalPeriod,” the “RenewTimeStamp” was also changed. I was curious if the RenewTimeStamp was the date the certificate needs to be renewed or something else. As shown below, I used the GetRegDate I mentioned in an older blog

As shown above, when our client is in a valid renewal period to renew the certificate, the client will reach out to the enrollment service and try to renew the certificate. When it fails the renewal, the “RenewTimeStamp” will be changed to the moment we tried to renew it!

So, I guess when looking back at the errors we got, manually changing those keys alone isn’t going to do it.

I guess we need to take another look at the Fiddler trace because I do not notice any Time Stamps in the Certificate Renewal Process, only the Certificate itself. Luckily that Certificate doesn’t mention the certificate validity period.. ow wait…

I guess it’s pretty safe to assume that there must also be a function inside the deviceenroller.exe that would also check the Intune Device Cert itself and if it’s eligible for renewal instead of looking at some registry keys

5. Device Cert Expiry Time

So, I decided to take a closer look at the devicenroller.exe process again and again and again. While doing so, I noticed some more cool functions, and going down the flow, it showed me these two additional functions, which are called upon from the main function CheckAndFixRenewSchedule

As shown above, when trying to renew the Intune MDM Certificate, the device enroller process will first check the renewal parameters and tasks, and guess what parameter will be checked? Yes!! It will call upon the “GetDeviceCertExpiryTime”. This function will try to find the Certificate’s expiry time by looking up the proper cert. It does so by first checking the DMPCertThumprint

This DMPCertThumprint is configured in the Enrollments GUID and specifies the thumbprint of your Intune MDM device certificate

Now the deviceenroller knows which Certificate it needs to check, it will determine the Intune Device Certificate Expiry Time.

This “device cert expiry time” will be compared with the “renew period in seconds“, the “renew retry interval in seconds” and the “System Time”. With this output, the device enroller determines if the certificate is ready for renewal. Of course, if the certificate isn’t eligible for renewal you will get the same nice error message I showed you earlier!

6. Service Side

So, until now, we have only talked about what is happening on the client side when the device needs to renew the Intune MDM certificate. We already noticed that when renewing the Intune certificate, the certificate is transferred to the enrollment service, but after reading the text below, I started wondering about the enrollment service a bit more

Of course, I don’t have access to the enrollment service side so this part is just about me thinking out loud and pure speculation.

What if it was possible for Microsoft to use the enrollment service to change the enrollment policy on the fly? As the device reaches out to fetch the certificate enrollment policies first… So, can the rules to be compliant be changed when the device reaches out?

What if it was possible for Microsoft to ALLOW EXPIRED or Extend the expiration date of Intune certificates?

Let me give you some examples of why I guess Microsoft could do the same(again just speculating)

Example 1:

When COVID started some years ago, people “left” their desktop pc at the company and started working from home, mostly from their own devices or a new one. I can’t remember any issues with expired Intune Certificates at that point in time. Did Microsoft decide to flip the switch to allow expired Intune Certificates? Because how else could those devices still communicate with Intune after being shut down for over a year?

Example 2:

This is a quote from someone he received from the Intune Product Team after reading my blogs about the missing Intune Device Certificate.

“In the meantime, we have marked the devices that you have indicated are not checking in with a temporary workaround which will allow them to check in and once again calculate compliance correctly”

So, Microsoft made a change service side, that allows a device with an expired Intunecertificate to check-in. When looking at another quote from that same message:

“The Windows OS team is working to resolve the issue with an update for Windows, due out as part of updates 9C and 9D (e.g. weeks 3 and 4 of this month).”

That does remind me of a problem with a Windows release from some time ago.

Example 3:

Intune MDM enrollment certificate not present after updating to a newer version of Windows – Microsoft Tech Community

I am wondering now if Microsoft decided to disable the requirement for a valid Intune certificate on the enrollment service when this issue started.

7. The Flow

I guess nothing looks better than a nice graphical overview of the renewal flow, right? So here you are!. As shown below, when the certificate renewal task is launched, it will determine if the certificate is up for renewal by comparing all of the timestamps it fetched.

If the device “thinks” the certificate needs to be renewed, it will send a renewal request to the enrollment service. The Enrollment Service will determine if the certificate is eligible for renewal and if so, it will send back a nice new Intune certificate. Of course, the request will be denied when it’s not eligible for renewal!

Conclusion

I can’t say it enough… it’s very important that the Intune Device certificate is NOT expired. That important certificate NEEDS to be renewed in time; otherwise, all communication with Intune will stop! Hopefully, this blog showed you some more information about what happens beneath the curtains when renewing the Intune certificate.