Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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).
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)
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.
Great! I'm still looking for a more permanent solution but this should prove helpful for both of us :-)
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).
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.
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
The certificate I get with WebClient is different that the one I retrieved separetely.
WebClient Subject Name is:
"OID.188.8.131.52=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.
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.
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
Fixed in mono
QA: unit tests added in master and ios6 branches
hotfix coming soon...
Created attachment 2760 [details]
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