We were having trouble with iOS clients automatically presenting users with the captive portal login form. Users had to attempt to visit a web page in Mobile Safari manually and then the login form would display. This is undesirable as most users are conditioned for the login form to present automatically and it seems like the WiFi network is malfunctioning.
In our case, after installing a domain-level wildcard SSL cert on vWLAN, users were prompted to accept the login form's untrusted cert. We use a GoDaddy/Starfield-issued cert and they provided a very nice FAQ page about this issue: Verifying a Certificate's Validity on Your Computer | GoDaddy Help | GoDaddy Support
So we added their six (at the time of this post) CRL and OCSP server hostnames as vWLAN network destinations, then created a destination group called "OCSP-CRL" and added the destinations to it. That made it simple to edit the Un-Registered role and append a firewall rule, allowing outbound HTTP to the OCSP-CRL destination group.
Now CNA seems to behave properly and our clients using iOS devices are presented with the captive portal login form immediately after associating with a relevant SSID.
It seems likely that SSL certificates issued by other providers would also be checked by clients in the same way. I would guess that a given certificate provider can provide similar Certification Revocation List (CRL) and Online Certificate Status Protocol (OCSP) service addresses. Hope this info is helpful if anyone encounters a similar challenge.