Bug 7664 - Invalid Certificate Received from Server
Summary: Invalid Certificate Received from Server
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 5.2
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2012-10-04 19:05 UTC by Bryan Moulton
Modified: 2012-10-26 19:14 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
updated Mono.Security.dll (282.00 KB, application/octet-stream)
2012-10-17 13:19 UTC, Sebastien Pouliot
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Comment 1 Sebastien Pouliot 2012-10-04 19:13:09 UTC
Already on it...

It would be great if he can c.c. himself to the bug report. It seems the server does not return the whole chain (and some people report iOS does not like that, API-wise, even if Safari itself does not mind).
Comment 2 Sebastien Pouliot 2012-10-05 11:47:53 UTC
MonoTouch's certificate trust decision is delegate to iOS itself. However it might not match Safari 100% of the time since it seems that Safari does a bit of processing when some things are missing.

The 0x5 code being returned maps to kSecTrustResultRecoverableTrustFailure. This means the trust could not be confirmed but that it _could_ be fixed (i.e. it's not refused, but not complete enough to be accepted either).

This can happen for several reasons. In this case it seems* related to a missing intermediate CA certificate. The https server is not configured to return the whole certificate chain (it only returns it's own certificate**) so insuffisant data is available for iOS to return a success code (hence the 0x5).

The easiest/fastest fix would be to update the server configuration as it would:

- likely fix this issue (and confirm my suspicion);

- make the network access faster (by not having to issue another HTTP request to get the intermediate certificate); and

- ensure that the trust can be confirmed even if the 3rd party server (where we could download the certificate) is unavailable.


* sadly iOS does not support some API that would describe the issue, I'll try to confirm this from OSX (which, hopefully, should behave identically).

** this is ok RFC-wise but it's not the default for most servers (mostly for the above reasons)
Comment 3 rasmus 2012-10-05 18:17:18 UTC
Hi Sebastian.

Thank you very much for looking into this.

I'm also in talks with Nodejitsu our hosting provider, and they think it will be fixed after a transition from godaddy to commodo, which they are currently going through.

Apparently they should be done with that on monday, so as soon as i can test it out i'll let you know.

Thank you
Rasmus.
Comment 4 Sebastien Pouliot 2012-10-05 18:24:44 UTC
Great! I'm still looking for a more permanent solution but this should prove helpful for both of us :-)
Comment 5 Sebastien Pouliot 2012-10-16 14:45:28 UTC
I can evaluate the trust correctly from MonoTouch itself, but not from
the WebClient (and the results should be identical). So there's a bug
hidden in there (and I'm looking into it).
Comment 6 rasmus 2012-10-16 16:51:03 UTC
Ah, great.

I'm still waiting for my host to change their certificate provider, so haven't been able to test against that yet.
Do you still think that it is an error in the chain as well?

Thank you - Rasmus.
Comment 7 Sebastien Pouliot 2012-10-16 16:59:12 UTC
I'm using https://api.imgur.com/2/stats (reported on the mailing-list) for my test. OTOH your chain was not in error, just incomplete, so it's likely the same issue. In any case I'll be testing the your server* once I find what differs between the two implementations I have in front of me.

* and a bunch of other (working) servers
Comment 8 Sebastien Pouliot 2012-10-16 19:58:45 UTC
The certificate I get with WebClient is different that the one I retrieved separetely.

WebClient Subject Name is:
"OID.2.5.4.5=EWOxzsmcA8KLm9-x4FmJYaQx0sobgC4T, C=US, O=imgur.com, OU=GT24122773, OU=See www.geotrust.com/resources/cps (c)11, OU=Domain Control Validated - QuickSSL(R) Premium, CN=imgur.com"

while the other one I got is:
CN=api.imgur.com, OU=Domain Control Validated - QuickSSL(R) Premium, OU=See www.geotrust.com/resources/cps (c)11, OU=GT13382594, O=api.imgur.com, C=US, SERIALNUMBER=Jj-6wNiUyc1j1w-dsJtowuRbij10QwfE

The string formatting differs (differnt class were used) but the fact remains, the second certificate is allowed to serve for "CN=api.imgur.com", while the first one is not, "CN=imgur.com".

It's possible that the server depends on some TLS extensions (e.g. many certificates/hosts handled by the same server instance) that Mono does not support. I'll confirm this with wireshark.
Comment 9 Sebastien Pouliot 2012-10-16 20:47:34 UTC
Confirmed, it's the 'server_name' extension. Without it mono[touch] does not receive the same certificate that the browser (e.g. safari on iOS) would get - so the result of the trust can differ.
Comment 10 Sebastien Pouliot 2012-10-17 10:16:48 UTC
Both your cases seems to when the server_name extension is implemented. It will need additional testing but I'll be able to provide you an hotfix to apply on top* of 6.0.5 (once released).

* 6.0.5 is already in progress so this fix won't be part of it
Comment 11 Sebastien Pouliot 2012-10-17 11:41:16 UTC
Fixed in mono
mono/master: e952b24079d080e2b0c77965773d4d24917238f7
mono-2-10: 892654f252aa8421cfee59eb0791fa734c33e33b
mobile-master: 3d2fef0e574c3b372c460f21605c6e9876034fe6
monotouch-6.0-series: 52ebf804c2ec58f4f5f39633fb5e6c1f3fcdf6e7

QA: unit tests added in master and ios6 branches

hotfix coming soon...
Comment 12 Sebastien Pouliot 2012-10-17 13:19:16 UTC
Created attachment 2760 [details]
updated Mono.Security.dll

To use the attached assembly (on top of MonoTouch 6.0.5*) do:

1) backup your /Developer/MonoTouch/usr/lib/mono/2.1/Mono.Security.dll and /Developer/MonoTouch/usr/lib/mono/2.1/Mono.Security.dll.mdb files

2) copy the attached file to /Developer/MonoTouch/usr/lib/mono/2.1/Mono.Security.dll

3) remove the /Developer/MonoTouch/usr/lib/mono/2.1/Mono.Security.dll.mdb symbols (they won't match anymore)

4) clean, rebuild and test your application

* there were no recent changes in this assembly - so the fix likely works on earlier versions of MonoTouch (6.x) too