Encoding Technique has been changed since iOS 11 beta 4

Getting Invalid data as part Profile Service while enrolling the device

As part of enrolling the device, we follow simple certificate enrollment protocol.

For PKI operation in that, device responds back with a encoded certificate.

That encoding technique has been changed from iOS 11 Beta 4, what exactly is the latest encoding technique that has been introduced ?

It is a breaking change for us, it would be great if we could get the response as early as possible.

Replies

I had same problem with ios 11 Beta 7/Beta 8. CSR is wrong data. I cannot decode them.

(Posting without links...I think that the links are causing me to get blocked)


In doing a quick scan of the traffic that the device generates during SCEP registration, it appears that the “+” and “/“ characters are no longer being %-encoded in iOS 11. In iOS 10 and earlier, they were %-encoded


This actually appears to be a bug in iOS 11…according to the specification for SCEP, the last paragraph of section 4.1 reads:

When using GET messages to communicate binary data, base64 encoding

as specified in [2] MUST be used. The base64 encoded data is

distinct from "base64url" and may contain URI reserved characters,

thus it MUST be escaped as specified in [8] in addition to being

base64 encoded. Finally, the encoded data is inserted into the

MESSAGE portion of the HTTP GET request.


The reference "[8]” is RFC 2396 - and in section 3.4, it reads:

Within a query component, the characters ";", "/", "?", ":", "@",

"&", "=", "+", ",", and "$" are reserved.


This seems to indicate to me that Apple has actually broken something in iOS 11. I validated this by setting up a proxy that will replace all “+” and “/“ characters in the message parameter with the appropriately-encoded values. Doing this *did* work, and I was able to register the profile.

Hi!


We had exactly the same problem and we fixed it 2 hours ago by "repairing" the encoding as well.

I was just going to post the solution, when I found your post ;-)


We have an "SCEPGateway" that redirects the SCEP traffic to the CA; before redirecting, we are now repairing the base64 encoded data ('/' is causing no problems, BUT '+' is urldecoded to ' ' by the webserver which breaks the base64 format).


The message-Parameter of the following operation is the cuplrit:
?operation=PKIOperation&message=<base64 encoded data>