It’s a lack of features in Apple’s code, and it’s very well-known among Apple 
developers.  Search Apple’s developer forums (both iOS & MacOS) as well as 
their public bug database (IIRC, you have to be a registered Apple developer to 
search those).  Apple’s not going to change it, though, as the code in 
question* is ONLY intended to read profiles signed by Apple’s tools — it’s not 
intended to be a generic PKCS#7 parser, even though the profiles are wrapped in 
a file that closely resembles PKCS#7.

As Dr. Henson previously replied (below), the order of certificates is 
insignificant for PKCS#7.  Again, these profiles are not really PKCS#7, and 
Apple is free to modify the format at any time.

TOM

* This is also why Apple tells everyone to use OpenSSL for processing the 
PKCS#7 messages for in-app purchases, not only is the API not public, but it’s 
not suitable for reading anything but a very limited subset of PKCS#7 for very 
limited purposes.  There’ve been rumblings on the Apple-CDSA list about that 
changing for years now, and while I didn’t check the iOS 7.1 APIs, I suspect 
that’s still not changed).

On Apr 22, 2014, at 1:50 AM, Satish Kamavaram via RT <[email protected]> wrote:

> Hi ,
> 
>   Do you have any update on this?
> 
> Thanks
> SatishKumaar
> 
> -----Original Message-----
> From: Satish Kamavaram 
> Sent: Friday, April 18, 2014 12:29 PM
> To: '[email protected]'
> Cc: [email protected]; Retheesh Ravi
> Subject: RE: [openssl.org #3316] Wrong trust chain with new version of 
> openssl 
> 
> We are not sure if it is a Apple iOS bug. Below is our observation.
> 
> - If we sign the profile using the 0.9.8 version, and download the profile 
> from an https location, the iOS profile installer shows the profile as 
> "Verified"
> - If we sign the same profile using the 1.0.1 version and download the 
> profile from an https location, the iOS profile installer shows the profile 
> as "Not verified"
> 
> The only difference between these two versions of openSSL visibly is, the 
> order in which the certificate is listed in the profile. Is there a 
> difference in these two versions that causes the difference in this 
> certificate listing order? Is there a way we can make the order same to make 
> it work while still using the latest version 1.0.1 of openSSL?
> 
> Thanks
> SatishKumaar
> 
> 
> -----Original Message-----
> From: Stephen Henson via RT [mailto:[email protected]]
> Sent: Wednesday, April 16, 2014 11:44 PM
> To: Satish Kamavaram
> Cc: [email protected]
> Subject: [openssl.org #3316] Wrong trust chain with new version of openssl 
> 
> On Wed Apr 16 19:37:20 2014, [email protected] wrote:
>> Hi ,
>> 
>> When the iOS WiFi Profile is signed using new openSSL 1.0.1 version, 
>> it specifies the certificate chain in reverse order causing the device 
>> not to recognize the certificate chain and show "Not Verified".
>> However, when we sign using version 0.9.8k, the chain is included in 
>> the correct order and the device is showing the profile as a 
>> "Verified" one , at the time of showing profile installation prompt.
>> Is there a possibility that we will get a fix in next version of 
>> openssl ?
>> 
> 
> I'm not sure what you mean by "correct order". The order of certificates in a
> PKCS#7 structure should not be considered significant and there is additional 
> information (issuer name and serial number) which should enable a verifier to 
> locate the appropriate signing certificate.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> 
> 
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [email protected]
> Automated List Manager                           [email protected]
> 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to