-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSUrlSessionHandler: Adds support for X509 client certificates #20434
Conversation
We don't have access to that class, so please just copy it over (and add a comment explaining where it came from).
I think it's fine to not mark it as supported (an alternative approach would be to mark it as supported, but throw some sort of "not supported exception" if someone tries to set it to Automatic). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@dotMorten it fails to build:
|
@rolfbjarne Fixed. Could you retry? |
|
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
💻 [PR Build] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11) failed ❌Failed tests are:
Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Monterey (12) failed ❌Failed tests are:
Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Ventura (13) failed ❌Failed tests are:
Pipeline on Agent |
📚 [PR Build] Artifacts 📚Packages generatedView packagesPipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
🔥 [CI Build] Test results 🔥Test results❌ Tests failed on VSTS: test results 1 tests crashed, 8 tests failed, 159 tests passed. Failures❌ monotouch tests (macOS)
Html Report (VSDrops) Download ❌ xammac tests🔥 Failed catastrophically on VSTS: test results - xammac (no summary found). Html Report (VSDrops) Download Successes✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
Hi @dotMorten. Due to inactivity, we will close this pull request in 7 days. |
Never mind that, we're still working on this. |
Looks like Apple is fixing this in macOS 15, Xcode 16 beta 1's header for
|
…es (#8961) Fixes: #7274 Fixes: dotnet/runtime#78933 Context: xamarin/xamarin-macios#20434 Update `AndroidMessageHandler.SetupSSL()` to use the `AndroidMessageHandler.ClientCertificates` collection when `AndroidMessageHandler.ClientCertificateOptions` is `ClientCertificateOption.Manual`, which is now the default. This allows the following code to work as expected: var certificate = … var handler = new AndroidMessageHandler { ClientCertificates = { certificate, }, }; var client = new HttpClient(handler); var result = await client.GetAsync(…); !!API BREAK!! the `AndroidMessageHandler.ClientCertificates` property is updated to now throw an `InvalidOperationException` when `AndroidMessageHandler.ClientCertificateOptions` is `ClientCertificateOption.Automatic`, meaning the following code will now throw, whereas it does *not* throw in .NET 8: var certificate = … var handler = new AndroidMessageHandler(); handler.ClientCertificateOptions = ClientCertificateOption.Automatic; // this now throws InvalidOperationException, new to .NET 9 handler.ClientCertificates.Add(certificate); This updated behavior is consistent with iOS (xamarin/xamarin-macios#20434) and [dotnet/runtime][0]: handler.ClientCertificateOptions = ClientCertificateOption.Automatic; Assert.Throws<InvalidOperationException>(() => handler.ClientCertificates); [0]: https://github.com/dotnet/runtime/blob/2ea6ae57874c452923af059cbcb57d109564353c/src/libraries/Common/tests/System/Net/Http/HttpClientHandlerTest.ClientCertificates.cs#L60-L68
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
/azp run |
No pipelines are associated with this pull request. |
Hi @dotMorten. Due to inactivity, we will close this pull request in 7 days. |
@rolfbjarne @mandel-macaque bot likes to close this. Curious what the hold up is at this point? This is a quite important feature for several of our customers |
@dotMorten It turns out the big problem with testing on macOS is gone now, because Apple added API to import certificates without needing access to the default keychain in macOS 15 (this was a big part of the delay, I wanted to test if Apple's new API worked, and it does, at least locally for me). I've updated the code accordingly. On the other hand, due to security changes/restrictions, our CI can't build PRs from forks anymore, so I re-created this PR here: #21284. Any further discussion should be done there. |
…icates (#21284) Addresses #13856 This was originally created by @dotMorten in #20434. Also make SecIdentity.Import use an in-memory keychain on macOS 15+, so that SecIdentity.Import works like all othe other platforms (i.e. not requiring access to the default keychain, which, among other things, is not ideal on bots). --------- Co-authored-by: Morten Nielsen <mort5161@esri.com> Co-authored-by: dotMorten <mn@iter.dk> Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Addresses #13856
There's a couple of outstanding questions for this PR, so keeping it in draft for now:
This relies on System.Net.Security.CertificateHelper which is internal. I'm not sure if xamarinios has access to this. If not, should I just copy the file over? It is for instance used here to pick the correct certificate in SocketsHttpHandler and HttpClientHandler.. Update: Imported a copy.I also toyed with having a public callback for users to do more native certificate handling, and modeled around the
ServerCertificateCustomValidationCallback
callback:This isn't in the PR, but more than happy to also add that. My thinking was that might enable some scenarios where you can't use the .NET X509 certificates but need to pull native certificate types in