Why we see certificate warning “ Domain/common name mismatch “ with Captive portal authentication


Why we see certificate warning “ Domain/common name mismatch error “ when we use HTTPs website to access captive portal page . 


It’s an expected behavior when we use HTTPs website. 

How HTTPs traffic are handled in case of captive portal authentication :

1) User types in HTTPS URL with IP or hostname in the browser.

2) The browser tries to resolve the DNS if it is a hostname

3) Then the client initiates the TCP handshake with that host . Controller captures this and completes the TCP handshake.

4) After the TCP handshake is completed, the client sends "start-tls" for SSL . ( In the case for HTTP the client sends HTTP-get request after it completes the handshake and controller replies with the redirect message  to https://securelogin.arubanetworks.com/cgi-bin/login?xxxxx  , then client takes this and generate a new https to securelogin.arubanetworks.com, there is no warning from client because it can't tell the IP of the HTTP was spoofed.)

5) However in HTTPs since the client sends the "start-tls" and request for certificate ,controller needs to reply back with its certificate either "securelogin.arubanetworks.com" or the customer acquired server cert hostname

6) Client downloads this cert and check the hostname (common name) against the original HTTPS:// URL hostname, since it was asking for a different hostname but it got the cert from controller - name mismatch is causing the warning message

Since HTTPS was designed to avoid MITM (man-in-middle-attack) and captive portal utilizies the same ,it’s expected to notice this domain/command name mismatch error when we use HTTPS url on the client when we try to get the Captive portal page


The only workaround to avoid this message is to use HTTP URL  instead of HTTPs URL on the client side.

Version history
Revision #:
2 of 2
Last update:
‎05-18-2016 01:37 PM
Updated by:
Labels (1)
Search Airheads
Showing results for 
Search instead for 
Did you mean: