Same NEHotspotEAPSettings works fine before iOS 15, which looks like this.
NEHotspotEAPSettings *eapSetting = [[NEHotspotEAPSettings alloc] init];
eapSetting.tlsClientCertificateRequired = YES;
eapSetting.supportedEAPTypes = @[@(NEHotspotConfigurationEAPTypeEAPTLS)];
eapSetting.preferredTLSVersion = NEHotspotConfigurationEAPTLSVersion_1_2;
eapSetting.outerIdentity = myVcardDict[@"mis"];
any idea? Thanks!
What part is failing here? Is it the outerIdentity string? Either way, this should be recorded as a bug report if the same code previously worked. Please follow up with the Feedback ID.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I have encountered the same problem, which has bothered me for several days. Have you solved it
Over the last few weeks I have run into a few issues on iOS 15 Beta with configuring NEHotspotConfigurationEAPTypeEAPTLS. (r. 79054571) and (r. 82698111). If you run into this, please make sure to open a bug report.
Now, in some cases I have been able to workaround any possible invalid settings issues by using an alternative EAP type, for example: NEHotspotConfigurationEAPTypeEAPTTLS, NEHotspotConfigurationEAPTypeEAPPEAP, or NEHotspotConfigurationEAPTypeFAST. If this is an option for your configuration, try this to see if it works for your environment.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Have the bug fixed yet?
Hey guys, I couldn't seem to find a solution around it. Did you have any luck with it?
Thank you so much!
I had the same problem although I was using PEAP. I have implemented a temporary workaround inspired by the fix used by the geteduroam app. They chose to set a trusted server name instead of supplying a certificate.
eapSettings.username = username;
eapSettings.password = password;
eapSettings.supportedEAPTypes = [NSArray arrayWithObjects:[NSNumber numberWithInteger:NEHotspotConfigurationEAPTypeEAPPEAP], nil];
eapSettings.outerIdentity = @"anonymous";
eapSettings.trustedServerNames = @[@"OUR-DOMAIN"];
You can find the Geteduroam tag with their fix here: https://github.com/geteduroam/ionic-app/releases/tag/v1.0.21
Tried the above configurations but those are not working. I have submitted a bug report for this issue. Details: FB9663301
Thank you for opening a bug report, I added an internal note to it.
Regarding:
I had the same problem although I was using PEAP. I have implemented a temporary workaround inspired by the fix used by the geteduroam app. They chose to set a trusted server name instead of supplying a certificate.
Thank you for sharing.
Yes, the two leading workarounds for this issue at the moment are to try and use another EAPType such as EAPPEAP and EAPFAST with an altered configuration for your NEHotspotEAPSettings. Or if you have MDM as an option, setting the setTrustedServerCertificates API with a certificate chain delivered from the WiFi.EAPClientConfiguration payload would be an option to try as well.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
We are facing same issue and our app is not usable without EAP-TLS method. Please fix this asap, its a blocker issue for our app. Can you please prioritize this . When can we expect fix ?
Please fix this asap, its a blocker issue for our app. Can you please prioritize this.
To be clear, Matt and I work for DTS and thus aren’t involved in fixing bugs. I recommend that you file your own bug about this, making sure to include details about the impact this is having on your users. Once you’ve done then, you should feel free to escalate this with your business contacts at Apple.
When can we expect fix ?
We cannot discuss The Future™.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Could you please let me know how to get business contact?
No, sorry. DTS is a technical support organisation and we can’t help with business issues.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
This issue remains outstanding. We have opened two tickets by now. The first one was 9650588, which was later replaced by the newer 9665978 (Feedback Assistant (apple.com)).
It's been two weeks since the second ticket and over one month since the first post in this forum! We have received zero feedback from Apple.
For us, this is such a show-stopper! We are in a terrible situation right now by Apple breaking this API entirely out of the blue!
Like everyone else on this post, we don't have a business contact. Does this mean we are pretty much doomed??
I found DTS was described as:
"DTS is the main technical contact for Apple's worldwide community of hardware and software developers, and as such we help ensure that the products they ship are designed to the high standards that Apple sets for itself. We answer a wide range of code-level questions, create sample code and other technical resources, and work closely with teams across Apple to continuously improve the Apple Developer experience."
It sounds to me that the DTS should at least have means or communications channels to help escalate the issue up the food chain?
Anyway, I would really appreciate any help or assistance!
Thank you!
It's been two weeks since the second ticket and over one month since the first post in this forum! We have received zero feedback from Apple.
I can see that your bug (FB9665978) was linked to the lead bug for this issue (r. 79054571) which has a fix. Now, there is no timeline that I can provide for when this fix will arrive in a build, my only advice to you here is to keep testing the iOS 15 Beta releases.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Hi Matt,
FYI, I just tried the most recent beta version 15.1, and the problem is still the same. :-(
To those who encountered the same problem, do you have any proven workaround that you might be able to share, please?
Just out of curiosity, how can I look up the lead bug for this issue (r. 79054571)?
There is no way to look this up on your end, I am simply adding this here so that it can be referenced that we are tracking this.
Regarding:
FYI, I just tried the most recent beta version 15.1, and the problem is still the same. :-(
Thank you for the report. Can you please update your bug report(s) with this information.
Regarding:
To those who encountered the same problem, do you have any proven workaround that you might be able to share, please?
I will let others chime in here, but some known workarounds I have seen used are to use a different EAP Type other than NEHotspotConfigurationEAPTypeEAPTLS so setting a custom root certificate as trusted does not have to be done with setTrustedServerCertificates.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Hi Matt,
Thank you for being so kind!
I have updated my ticket to say that the latest iOS beta 15.1 (19B5068a) still suffers from the same problem. But I'm not sure anyone would be monitoring my bug report since no one has ever commented on it. I certainly hope so, though. (fingers crossed)
After trying almost every possible scenario, apart from changing the EAP type (because that calls for changing the entire architecture), the only workaround we have found was using a commercial certificate, which, unfortunately, is a well-known vulnerability.
So does anyone here have any better solutions, please?
Thanks in advance!