Profile Installation Failed the SCEP server returned an invalid response maas360

I'm trying to experiment with configuration profiles and in order to do that I am starting out with one created by Apple's Profile Manager application that uses SCEP. When I take the .mobileconfig file and install in on the device (using Apple Configurator 2) it installs fine without any issue.

However, I noticed that if I modify anything in this profile (even something minor like "PayloadDisplayName") the enrollment process gets to the end but ends up failing with this error:

Looking at console logging doesn't show much of use:

It seems there is some sort of signing or checksum being used, but this is strange since the profile specifically says it is not signed. Looking at all the fields in use, the only thing I can guess is that the challenge field is somehow involved. Apple's documentation gives a hint about this field here:

The front end service can be set up to gate access by means of a challenge, which in practice is an authorization token (a one-time password, or a signed/encrypted blob containing user/device info) to allow automatic issuing of a certificate.

However the above is only a recommendation, and I am not able to find out how the challenge parameter is actually defined (the value I am using is oBGLAsWsMWnHiycHpBaHXNmVEDevrLt). I'm using the SCEP server that comes with Profile Manager but I have been unable to find any documentation about this, and the logging that is supposed to be present in the console log (with key "com.apple.SCEP") doesn't seem to exist.

If I remove the challenge parameter completely from the profile, I get a prompt during device enrollment, but I'm not sure what I should be putting in there.

If anyone has any ideas, please let me know.

UDPATE: Looking in /Library/Logs/ProfileManager/dmSCEPService.log I see these errors:

This confirms it is the challenge causing the issue, but I'm not sure how to generate a proper challenge so things will succeed.

A while ago a colleague turned to me for help. Customer tested iOS, Android and Win10 with a SCEP server. Win10 and Android had no issues, but on iOS the certificates failed to install with a cryptic error. I decided to write a blog about it, because I expect a second wave of such issues to hit on Sep 1 2020. Why, you ask?

What do we know?

First of all, the error message itself was interesting (sorry, the customer did not want to allow any screenshots). The first error message in the WS1 UEM console was just “SCEP request failed”, but when going into details we could see the following error

“Profile Installation Failed. The SCEP server returned an invalid response.”

What was also interesting, is that the error codes returned were not typical WS1 UEM error codes, for example 22013 – we just don’t use five-digit codes! In addition, the SCEP server logs showed that the device actually never requested the cert – it contacted the SCEP server, the server responded with its own cert, and the device closed the connection immediately (I will not go int details of SCEP handshake here, since it is not relevant to the case – these steps are all we need to know).

What could it be then? To answer this, we need to understand the process.

There are two ways to install a SCEP certificate on a device with WS1 UEM, using two different profile payload types Credentials or SCEP

• Credentials payload – WS1 UEM explicitly installs a certificate on a device as a binary file. The file may be uploaded to the console by an admin (this is how you typically push Trusted Root CAs) or requested from a CA by the WS1 UEM itself. Pretty much any platform supports this payload.
• SCEP payload – the device itself talks to the CA and requests a cert. WS1 UEM just sends the details (which SCEP server, etc) Not all OSes support it though. Android, for instance, does not have native SCEP support. Thus, on Android SCEP certs can only be installed using the Credentials payload, where WS1 UEM acts as a “proxy” that requests the cert from the SCEP server, upload it to the device and installs it as a binary file.

At this point, you can probably guess my next question, right?

How do we troubleshoot?

“Dear Mr Customer, how exactly are you pushing the certs?”

Of course, they used Credentials on Android and Windows, and SCEP on iOS! At this point, we can form a viable hypothesis, that the device itself rejects the cert, potentially not liking something about the SCEP server. Experienced Apple admins probably already know, what it could be.. 🙂

First, I asked them to change the payload type to Credentials and try installing the cert again. It failed, but:

• The error messages were different – now I could see typical WS1 UEM messages
• The SCEP server actually showed UEM requesting the cert

This only strengthened my suspicion, that the rejection happens on the device.

Then, we looked into detailed iOS logs (with SCEP payload). There we could see all those weird strings and error codes – now I know how they appeared in the UEM console! Googling for the adjacent strings such as “MCSCEPErrorDomain” allowed me to find a piece of Apple’s documentation, that explained the codes themselves. Here’s an exerpt.

I don’t remember the exact code we were seeing, but it prompted us to look closed at the SCEP server cert.

Once we looked at it, it all became clear. Can you guess what it was?

What was the problem?

Apple devices are known to be very picky about the certs they trust. There is an official KB article just for that called “Requirements for trusted certificates in iOS 13 and macOS 10.15”. If you work with iOS and had not seen it yet – bookmark it, and read the note at the end of this blog, because those requirements will change soon!

From that KB, the cert of the SCEP server itself was violating two rules:

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Their cert had to SAN at all, only CN

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Their cert was valid for 20+ years

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

Which basically explains why the device was closing the connection to the SCEP server w/o even trying to request the cert.

Case closed!

Important note!

Apple had issued another KB detailing upcoming limits on trusted certificates Make sure to read that one too! Key thing:

TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days.

Summary

Now you know

• How picky Apple’s devices are about their certs, and which two official Apple’s KBs list the exact requirements
• How SCEP certificates are installed on different platforms using WS1 UEM
• How to collect in-depth iOS logs (if you have a Mac, if you have Windows – read this)
• What piece of Apple’s documentation contains the MDM-related error codes seen in those logs
• How you can approach troubleshooting such issues

Was that good? Have you ever bumped into such an issue yourself? Let me know!

P.S. Personal note regarding SCEP:

Every time you deal with SCEP, please keep in mind, that just like SNMP and many other protocols that begin with “Simple”, it was never intended as long-term stable solution. SCEP has TONS of limitations, issues (including security weaknesses) and quirks, and generally I would NEVER advise it as a first option. Workspace ONE UEM has lots of different implementations that work A LOT better in terms of stability, scale, breads of options etc. and I would ALWAYS recommend that you evaluate those first, and ONLY use SCEP as a last resort option.

There, now you’re warned!