Showing results for 
Search instead for 
Did you mean: 

ISE1.1 - Guest captive portal certificate error solution - LWA & reverse proxy


When a guest receives an error from browser that site you are accessing is untrusted and unsafe, it leaves wrong impression and bad reputation of the company. It results in major audit findings where corporate information security is also cruicial for the business. This error used to bother also when guest connects to an enterprise wireless guest network running ISE1.1 at backend with AD integration of which domain is internal ( and not public( Below are some possible solutions:

- upgrade to ISE1.2 (worth to consider ISE1.2 stability, thorough testing of all test cases and expiry of support of internal domain by public CA)

- use LDAP integration instead of AD (worth to consider the cons in terms of resilance comparing with AD integration)

- use reverse proxy along with LWA in WLC (explained in this document in detail, a permanent solution)

Upgrade to ISE1.2

ISE1.1 has some limitations which are resolved in ISE1.2 resulting in certificate error free guest captive portal:

- CN of the binded certificate used for management (https) should be same as FQDN of ISE1.1 node

From the link above:

"Note: If you check the Management Interface check box, ensure that the CN value in the Certificate Subject is the fully qualified domain name (FQDN) of the node. Otherwise, the import process will fail."

There can only be two methods to overcome this limitation, either use SAN certificate with ISE1.2 or use of disjoint namespace AD and continue using ISE1.1.

SAN certificate with internal FQDN ( as alternate names and CN as public ( can be an easy solution when upgraded to ISE1.2 till public CA supports internal domain as alternate names in SAN certificates.

Second option where AD with disjoint namespace is used: When ISE nodes are integrated with AD, it appears as a computer account in AD that's the reason ISE/AD integration requires an AD account with privilege of adding a computer in domain. Typically when an AD integratable client Windows machine (for example - Windows 7 with hostname: win7) is joined with AD (company.domain), machine hostname is changed automatically and appended with AD domain name ( but AD doesn't have this control over ISE that AD could change ISE FQDN accordingly when ISE node joins the domain. Well, AD ofcourse has control over itself and therefore AD stops communication with ISE unless FQDN is same as required by AD (that is It means ISE should be integrated with AD which supports both internal and public domain names for its member computers which is possible when AD supports disjoint namespace. By the way, AD infrastructure with disjoint namespace is not common.

- Wildcard certificate is supported in ISE1.2

Wildcard certificate is not supported in ISE1.1 while is supported in version 1.2 but If windows supplicant is being used for client authentication, then wildcard certificate may not work.

From the link above:

Q: is it possible for me to use a 3rd party certificate with EAP server? Can I use wildcard certificates?

A: It's possible to use 3rd party certificates. Provided that they are valid and have few other restrictions (validity, expiration, chaining to a proper root...etc)

Q: is it possible for me to use a 3rd party certificate with EAP server? Can I use wildcard certificates?

A: However, Wildcard certificates are not allowed

Although the link is about Windows Vista and Longhorn but still risk is not worthy. One dot1x problem was noticed in Windows 7. Similar problem was confirmed by Microsoft for Windows Vista and Windows Server 2008 with hotfix which was used along with some registry change to fix the problem in Windows 7 therefore looks like Windows supplicants are using similar code therfore Windows 7 supplicant may also be unstable due to wildcard certificate like Vista.

Use LDAP integration instead of AD

It has been explained with reason of AD integration that ISE1.1 has limitation of FQDN be same as CN of binded certificate. It is noticable that main problem is AD integration requirement that machine hostname should be internal like AD ( This integration is essential to use AD as external identity source. AD as external identity source can be used via LDAP integration. Main advantage is that LDAP integration doesn't require the FQDN of ISE node to be appended with domain name that is FQDN can be configured as which can definitely be CN of trusted public certificate and inturn trusted by guest also. LDAP and AD integration has its own advantages and disadvantages as explained in below link:

Difference is in terms of supported protocols (MSCHAPv2 etc is not supported in LDAP) as well as resiliency that the AD integration offers (automatic binding to closest AD server and failures, instead of using a sequence of LDAP servers (if 1 fails try the next, etc.))

Use reverse proxy along with LWA in WLC

Usually it is recommended to use Central Web Authentication (CWA) when ISE PSN is used as radius NAC for WLAN SSID but since in CWA guest is automatically redirected to ISE1.1 PSN which has above mentioned limitations; certificate error cannot be removed. Redirection at every stage which was weekness of Local Web Authentication (LWA), can help to remove the error. How LWA works, is explained in many other documents - one of useful link is as below. Please note that in referenced link (configuration example) guest has been redirected to ISE1.1 PSN which results in certificate error.

WLC redirects only HTTP traffic as redirection starts by intercepting HTTP GET request which is generated after successful TCP handshake upon guest's browser try to request data from internet website (for example:

In WLC, instead of configuring "External WebAuth URL" to ISE1.1 PSN guest portal; if it is URL which is hosted on reverse proxy server; certificate error problem can be resolved. When WLC redirects the traffic that is actually the first redirection of LWA process, WLC appends the URL with additional information - specially the details about the site which guest wanted to access and was interrupted by WLC however, this change in URL doesn't affect reverse proxy settings or public certificate.


Reverse proxy server should have a trusted public certificate binded with this link so that when the traffic is redirected to reverse proxy guest wouldn't receive untrusted certificate error. Public certificate can be of any type like simple, SAN or wildcard. Reverse proxy server should be configured to forward the connection to ISE PSN ( without any type of change in packet headers or in other words reverse proxy server should be invisible to ISE and WLC. HTTPS session between guest browser and ISE1.1 is established successfully without any certificate error. ISE returns guest portal page to guest browser where guest enters the credentials, accepts AUP and changes the password.

Here starts the second redirection of LWA process. Guest portal redirects the guest browser back to WLC with credentials guest entered and WLC is responsible now for initiating the authentication process with radius server configured in WLAN security configurations. Guest portal also included the request to open the website which guest wanted to access after the successful authentication. RadiusServer.PNG

WLC queries radius server (that is actually ISE1.1 PSN). Note that there is no guest interaction in this process and all these steps are taken care at backend. Credentials are authenticated by ISE and upon success (Radius: access-accept), guest browser is finally redirected to URL configured in "Redirect URL after login". Yes, it is a bit wierd that during second redirection, original URL which guest actually wanted to access was passed to WLC but still WLC opens the URL which is configured in "Redirect URL after login".

"Redirect URL after login" shouldn't be left blank and should be an HTTPS link which is unnterceptable otherwise successfully authenticated guest again receives local authentication portal which is of WLC. Rest of the configuration of WLC that is of WLAN SSID and ISE will be same as mentioned in above link: Identity Services Engine Guest Portal Local Web Authentication Configuration Example.

Additionally, WLC virtual interface DNS host name should be changed and can be public because WLC supports publicly trusted certificate binding.


It helps! Actually, when guest login is successful, guest can see two browser windows. The larger window indicates successful login and can be used to browse the internet. Smaller window is required in order to log out when use of the guest network is complete. The screenshot shows a successful redirect for web authentication. If WLC wouldn't have public certificate, guest will receive same certificate error because this page is from WLC and not from reverse proxy where public certificate was already binded.


Below is a link explaining how to generate CSR and download unchained certificates to WLC.

By using reverse proxy with local web authentication, guest captive portal can be free of certificate error. It can also be considered as permanent solution because it doesn't use any internal domain name which could be expired by public CA.

Content for Community-Ad