HTTPS Captive Network wifi disconnect

I've asked this before but am asking again, as it is still an issue as of High Sierra beta 9.

My Apple devices running ios 11 and Mac OS 10.13 High Sierra will disconnect their wifi connection immediately if the server responding with captive portal uses https. Our company's captive portal has the option to force end systems to use https for it, so if it receives an http request for a portal, it responds with a port 443 redirect request. This appears to be neglected by the new OS's captive network assistant which then, simply, drops the wifi connection completely.

In currently released iOS and Mac OS's, the wifi connection does not drop - it just simply won't display the portal when our redirection is issued. The new beta systems, though, just disconnect the wifi connection immediately. This is hugely problematic as there is no workaround for end systems other than for system administrators to disable the https requirement for the captive portal.

Is this a known issue and/or is there any workaround from an end-system perspective? I did not find any topic like this on the forums as of yet.

I need to know if there is a workaround and/or fix in the works for this. I don't see why the wifi connection would disconnect for High Sierra/iOS 11 whereas other Mac OSes stay connected. Seems like an issue.


Post not yet marked as solved Up vote post of moooooog35 Down vote post of moooooog35


Any update on this or work arround...

Else need a way to roll back to older version of OS.

I haven't heard anything about this and am now starting to get complaints from customers attempting to attach to our captive portal that uses https. The wireless connection on the end system attempting to connect is immediately dropped. I've tried trusting the certificate separately, but that doesn't seem to have any effect.


I have resolved it by assigning IP address manually and then connect to captive network once using safari.

Now its working fine.

Hi there!

I have faced the same issue as described. In my company there are two wifi networks. The public one, and the internal one. The internal one is protected by captive portal. I had no trouble to connect to the public one, but all connection attempts to the internal networks was imedietaly refused.

I have solved this issue by the full recovery of High Sierra. It seems that upgrade is broken and full reinstall could be the solution.

Facing the same issue described above. Like sirtmp's situation, there is also a public and an internal network at my company. No trouble connecting to the public one. For the internal network, we connect using EAP-TLS mode, then supply a certificate. The certificate has been trusted, however when connecting to the internal network using a Mac with High Sierra, it seems to connect for a split second then immediately disconnect. Users with Sierra do not have this issue and can connect to both networks fine.

I have tried plain reinstalling the OS and completely restoring the machine by erasing the disk and then reinstalling the OS, as suggested above, both to no avail.

This is affecting our employees' ability to do work, and is considered a major issue, since there is no Apple-provided way to downgrade to Sierra unless the user has a bootable Sierra install drive premade. They have been instructed not to upgrade until we have a fix.

Is there any new word from Apple on this or a workaround that has worked for others?


Sumit's suggestion certainly helped me, not actually on Mac OS 10.3 but on iOS 11(.0.2).

My company's wifi portal has a captive portal that is accessed via https. Since I upgraded to iOS 11(.0.1 and then .0.2), I would try to connect to the wifi and then after maybe a second would be disconnected.

Using Sumit's description as inspiration, I clicked to connect to the wifi button, then on the second that the wifi seemed to connect I hit the i icon which takes you to the screen where you can see your assigned IP address, submask, and router IP. Since this all goes away in less than a second, I took a screenshot so I could read what it said for my IP.

I then used a colleague's phone to get what the DNS for that captive wifi is, and also the appended domain suffixes to be searched.

Having these five pieces of information I was then able to configure the wifi with manual settings (IP address, subnet mask, router IP, DNS address, and suffixes). I then clicked connect and wasn't disconnected. It took a few seconds for the Wifi bars to appear so that "regular" apps like Safari could browse, but once it did I opened Safari and tried browsing to a non-https site and then got redirected to the captive portal page on which I logged in regularly with success.

Thanks Sumit!

The same thing here. So I opened the network panel > Advanced > TCP/IP, connected to wifi and took a screen capture of the IP address, subnet mask and router (a phone works too), then manually entered. I'm now connected. Thanks for the help!

One thing we found that works as a work-around was navigate manually to the captive portal site in a web-browser.

Lots of them have the standard: or addresses.

All iOS deivces that we've permitted to upgrade to iOS11 are experiancing this issue.

Guest wireless connects, devices obtain an IP, but when the captive portal pops up on the device it immeditaly goes away and disconnects.

Our workaround for iOS 11 devices:

  1. On your iOS device, install a separate browser; Firefox
  2. Once connected to the guest wi-fi disable auto-join:

    Tap the ℹ next to the network name and turn off Auto-Join

  3. Use Firefox and navigate to the address: or (whichever your captive portal uses)
  4. This will redirect to the captive portal login page where you can enter your credentials

The problem with the majority of these workarounds is that captive portals are customer/user facing. Apple can't ask an end user to screen shot his/her network screen in a stadium, for example.

Also, you don't really have this option via mobile devices without closing everything individually when the sign-in screen pops up. The connection is already gone by that point.

I've also found that 802.1x requests are failing when Sha1 certs are being used for RADIUS authentication. The fact that they completely pulled the TrustStore configuration out of iOS really *****. I have no way to manually trust/import a certificate on my iOS devices now.

Not sure *** they 're doing in Apple but they are making the user experience unbearable if the keep locking things down without giving us valid workarounds or accessbility.

I've found a solution that I consider tenable until Apple addresses the issue.

Again, for background, my company has an external and an internal, captive network. Users on High Sierra connecting to the internal network are immediately disconnected.

After a few weeks of looking, we believe the issue is being caused by Apple's Captive Network Assistant (CNA). It's a small utility that runs when you connect to a network and attempts to "phone home" to Apple and detect if the network you've connected to is a captive network. Internal company networks and portals often use these types of networks, as do many airports, hotels, etc. Long story short, something changed with High Sierra, and the CNA's default behavior seems to have changed.

We found that disabling the CNA solves the problem. To our knowledge, this doesn't introduce any new risk or security vulnerabilities (highly important for my company), as all the CNA does is try to detect a captive network.

To disable the CNA, run the following command in the terminal:

sudo defaults write /Library/Preferences/SystemConfiguration/ Active -boolean false

If that preference doesn't exist in your SystemConfiguration folder, it will be created.

We had to reboot afterward for the change to take effect. Once we reboot, forget the network and attempt to connect again and provide our certificate, and it connects and stays connected. No additional changes necessary, and you won't have to repeat after reboot or disconnecting.

If you need to re-enable the CNA for whatever reason, simply run the same command again but change the boolean at the end to true instead of false.

If anyone has additional information to add or knows more about the CNA, feel free to reply.

Nice to know that I'm not the only one suffering with this problem.

Our Captive Portal is generated by our Watchguard Firewall, which also acts as our DHCP server.

I have checked the DHCP logs after the attempted connection by either the iOS11 or 10.13 machines and I can see that a lease has been granted to them.

The "work around" I have for them is to,

Go into the network settings and input a static address from outside the Captive Portals DHCP range, then the device connects wirelessly to the network.

As soon as the device has connected I go back into the network settings and return it to the auto DHCP setting. renew the lease and the device then connects to the network.

I've also noticed that 10.13 devices on ethernet connections are not affected.


Looks like they've made some tweaks to this in iOS 11.2 Beta and High Sierra 10.13.2 beta. My wifi no longer disconnects.

It does NOT redirect to the captive portal over https, though. It goes direct to I'm sure this is probably a work in progress, as this is only Beta 1, but it's certainly better than the wifi connection dropping.

Good luck everyone!


I'm network eng. for a company having Aruba controlers. We have the same issue since Mac OS 10.13 (including 10.13.1) and IOS 11 (all versions but it depend devices !). We are running on last version of ArubaOS, and the support told us it's Apple issue, so....

On IOS11:

- Works on Iphone 7 (all versions).

- Works on IPad Air 1 (only since 11.0.3).

- Don't work on IPhone 8.

On MACOS 10.13

- Don't work at all exept if i disable SSL on the captive portal of the controler, the CNA open the authentication popup but on HTTP. Works too if i disable the CNA but we have to login with Safari and know the exact URL of the captive portal to avoid SSL error.

What is your Wifi controler/AP vendor?

Same problem here, with all devices on iOS 11 (<=11.1.1), that has no captiveportal bypass (by MAC adresses). We use pfSense with a self signed HTTPS cert. disable captiveportal or add the MAC adress of the device to the white-list and it works. One strage thing, the problem exisits only a WPA2 Personal Network with PSK (AES). A open wifi with captiveportal and https works fine.

BTW: iOS 11.2 Public Beta 2 seams to work for now