Watch your certificates when working with Apple devices!

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

Different ways to install a SCEP certificate via WS1 UEM
  • 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.

22000Invalid key usage
22001Cannot generate key pair
22002Invalid CAResponse
22003Invalid RAResponse
22004Unsupported certificate configuration
22005Network error
22006Insufficient CACaps
22007Invalid signed certificate
22008Cannot create identity
22009Cannot create temporary identity
22010Cannot store temporary identity
22011Cannot generate CSR
22012Cannot store CACertificate
22013Invalid PKIOperation response
Apple’s MDM MCSCEPErrorDomain error codes

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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

<span>%d</span> bloggers like this: