Wireless Access

Hi all,

We are experiencing an issue where wireless Android clients do not trust the wildcard certificate used for the Captive Portal. We have configured a Open wireless Guest network for Guests to access. The Guest network uses the (build-in / self-hosted) Captive Portal feature of the Mobility Masters / Controllers. We uploaded a wildcard certificate that matches our domain name / the url of the captive portal.  

Once we connect with a Windows laptop or Apple iPhone device, the captive portal works just fine. No certificate warnings or issue's. If we try a (random) Android device, we get two certificate warnings about not being able to verify the certificate. If we click on advanced, continue, the portal gets shown. 

We have investigated this issue ourselfs. To us, it seems like Android doesn't trust the (Root-)CA of the wildcard certificate by default, while Windows / Apple devices do. 

We tried to upload the full chain by performing the following steps: 

1. Connecting to the Guest WiFi as a client and opening the Captive Portal.
2. Saving the full chain as separate .cer files.

1. Dissect our wildcard.pfx to a wildcard.cer and wildcard.key
2. Combined all files into one .cer (like described here: https://community.arubanetworks.com/community-home/librarydocuments/viewdocument?DocumentKey=fcea273b-7b0f-43cd-b442-41d58022df1a&CommunityKey=39a6bdf4-2376-46f9-853a-49420d2d0caa&tab=librarydocuments).
3. Renamed the .cer file to .pem
4. Successfully uploaded the .pem to the Mobility Master (Managed Network > Configuration > System > Certificates) + the private key string of our wildcard.
5. Selected the new certificate as Captive Portal certificate (Managed Network > Configuration > System > More > General > Captive Portal Certificate).
6. Tested it with a random Android device > no luck, still the same certificate warning message.

Additional info:

We use the same wildcard / chain on other websites (e.g. XYZ.domain.com), that do get trusted by Android devices. We think the difference between the captive portal and the website is as follows: 

• Google Chrome / Microsoft Edge browser on Android does trust the certificate when browsing to website XYZ.domain.com. > Most likely used the build-in Chrome / Edge certificate trust list?
• Android built-in browser (automatically used when opening the Captive Portal) doesn't trust the certificate > Most likely uses OS certificate trust list.

We are using ArubaOS Software Version - 8.7.1.7. Anyone else experienced this issue before? 

Thanks in advance! 

------------------------------
Lex
------------------------------

Hello Lex,

I've seen issues with Android in the past. Which certificates has been included in the certificate chain that is uploaded to the Mobility Conductor? The root should not be included in the chain but the intermediate certificate do. Some certificates has multiple intermediates in the chain and some certificates are cross signed which can result in issues of the imported chain is not correct.

Beside this, please also make sure that the endpoint could reach the CRL, OCSP and AIA server that is included in the certificate. The client could use this information to build the chain and check the certificate status.

Hi all,

We are experiencing an issue where wireless Android clients do not trust the wildcard certificate used for the Captive Portal. We have configured a Open wireless Guest network for Guests to access. The Guest network uses the (build-in / self-hosted) Captive Portal feature of the Mobility Masters / Controllers. We uploaded a wildcard certificate that matches our domain name / the url of the captive portal.  

Once we connect with a Windows laptop or Apple iPhone device, the captive portal works just fine. No certificate warnings or issue's. If we try a (random) Android device, we get two certificate warnings about not being able to verify the certificate. If we click on advanced, continue, the portal gets shown. 

We have investigated this issue ourselfs. To us, it seems like Android doesn't trust the (Root-)CA of the wildcard certificate by default, while Windows / Apple devices do. 

We tried to upload the full chain by performing the following steps: 

1. Connecting to the Guest WiFi as a client and opening the Captive Portal.
2. Saving the full chain as separate .cer files.

1. Dissect our wildcard.pfx to a wildcard.cer and wildcard.key
2. Combined all files into one .cer (like described here: https://community.arubanetworks.com/community-home/librarydocuments/viewdocument?DocumentKey=fcea273b-7b0f-43cd-b442-41d58022df1a&CommunityKey=39a6bdf4-2376-46f9-853a-49420d2d0caa&tab=librarydocuments).
3. Renamed the .cer file to .pem
4. Successfully uploaded the .pem to the Mobility Master (Managed Network > Configuration > System > Certificates) + the private key string of our wildcard.
5. Selected the new certificate as Captive Portal certificate (Managed Network > Configuration > System > More > General > Captive Portal Certificate).
6. Tested it with a random Android device > no luck, still the same certificate warning message.

Additional info:

We use the same wildcard / chain on other websites (e.g. XYZ.domain.com), that do get trusted by Android devices. We think the difference between the captive portal and the website is as follows: 

• Google Chrome / Microsoft Edge browser on Android does trust the certificate when browsing to website XYZ.domain.com. > Most likely used the build-in Chrome / Edge certificate trust list?
• Android built-in browser (automatically used when opening the Captive Portal) doesn't trust the certificate > Most likely uses OS certificate trust list.

We are using ArubaOS Software Version - 8.7.1.7. Anyone else experienced this issue before? 

Thanks in advance! 

------------------------------
Lex
------------------------------

Hi William,

Thanks for your quick reply. Currently we tried uploading and testing the following:

1. Wildcard certificate only (.pfx including private key)
2. Full certificate chain (Root-CA, Intermediate-CA and Wildcard cert + private key - not in this order, but as described in the forum post).

I will try uploading a .pem file excluding the Root-CA, including the Intermediate-CA and wildcard + private key. 

Regarding your second option, how do we make sure it is possible for the client to verify this? Do we need to change the ACL for the 'Captive Portal' role? Do you have any recommendation / guide on how to properly set this up?

Thanks again! 

Hello Lex,

I've seen issues with Android in the past. Which certificates has been included in the certificate chain that is uploaded to the Mobility Conductor? The root should not be included in the chain but the intermediate certificate do. Some certificates has multiple intermediates in the chain and some certificates are cross signed which can result in issues of the imported chain is not correct.

Beside this, please also make sure that the endpoint could reach the CRL, OCSP and AIA server that is included in the certificate. The client could use this information to build the chain and check the certificate status.

Hi all,

We are experiencing an issue where wireless Android clients do not trust the wildcard certificate used for the Captive Portal. We have configured a Open wireless Guest network for Guests to access. The Guest network uses the (build-in / self-hosted) Captive Portal feature of the Mobility Masters / Controllers. We uploaded a wildcard certificate that matches our domain name / the url of the captive portal.  

Once we connect with a Windows laptop or Apple iPhone device, the captive portal works just fine. No certificate warnings or issue's. If we try a (random) Android device, we get two certificate warnings about not being able to verify the certificate. If we click on advanced, continue, the portal gets shown. 

We have investigated this issue ourselfs. To us, it seems like Android doesn't trust the (Root-)CA of the wildcard certificate by default, while Windows / Apple devices do. 

We tried to upload the full chain by performing the following steps: 

1. Connecting to the Guest WiFi as a client and opening the Captive Portal.
2. Saving the full chain as separate .cer files.

1. Dissect our wildcard.pfx to a wildcard.cer and wildcard.key
2. Combined all files into one .cer (like described here: https://community.arubanetworks.com/community-home/librarydocuments/viewdocument?DocumentKey=fcea273b-7b0f-43cd-b442-41d58022df1a&CommunityKey=39a6bdf4-2376-46f9-853a-49420d2d0caa&tab=librarydocuments).
3. Renamed the .cer file to .pem
4. Successfully uploaded the .pem to the Mobility Master (Managed Network > Configuration > System > Certificates) + the private key string of our wildcard.
5. Selected the new certificate as Captive Portal certificate (Managed Network > Configuration > System > More > General > Captive Portal Certificate).
6. Tested it with a random Android device > no luck, still the same certificate warning message.

Additional info:

We use the same wildcard / chain on other websites (e.g. XYZ.domain.com), that do get trusted by Android devices. We think the difference between the captive portal and the website is as follows: 

• Google Chrome / Microsoft Edge browser on Android does trust the certificate when browsing to website XYZ.domain.com. > Most likely used the build-in Chrome / Edge certificate trust list?
• Android built-in browser (automatically used when opening the Captive Portal) doesn't trust the certificate > Most likely uses OS certificate trust list.

We are using ArubaOS Software Version - 8.7.1.7. Anyone else experienced this issue before? 

Thanks in advance! 

------------------------------
Lex
------------------------------

Hi Lex,

You can allow these URL's in the allow list in the captive portal profile.

The destinations needs to be fetched from the server and intermediate certificate.

Example CLI config. 

For this example make sure DNS works on the controllers

netdestination comodo
  name crl.comodoca.com
  name ocsp.comodoca.com
  name rapidssl-crl.geotrust.com
  name rapidssl-ocsp.geotrust.com

aaa authentication captive-portal "<example>"

   white-list "comodo"

Hi William,

Thanks for your quick reply. Currently we tried uploading and testing the following:

1. Wildcard certificate only (.pfx including private key)
2. Full certificate chain (Root-CA, Intermediate-CA and Wildcard cert + private key - not in this order, but as described in the forum post).

I will try uploading a .pem file excluding the Root-CA, including the Intermediate-CA and wildcard + private key. 

Regarding your second option, how do we make sure it is possible for the client to verify this? Do we need to change the ACL for the 'Captive Portal' role? Do you have any recommendation / guide on how to properly set this up?

Thanks again! 

Hello Lex,

I've seen issues with Android in the past. Which certificates has been included in the certificate chain that is uploaded to the Mobility Conductor? The root should not be included in the chain but the intermediate certificate do. Some certificates has multiple intermediates in the chain and some certificates are cross signed which can result in issues of the imported chain is not correct.

Beside this, please also make sure that the endpoint could reach the CRL, OCSP and AIA server that is included in the certificate. The client could use this information to build the chain and check the certificate status.

Hi all,

We are experiencing an issue where wireless Android clients do not trust the wildcard certificate used for the Captive Portal. We have configured a Open wireless Guest network for Guests to access. The Guest network uses the (build-in / self-hosted) Captive Portal feature of the Mobility Masters / Controllers. We uploaded a wildcard certificate that matches our domain name / the url of the captive portal.  

Once we connect with a Windows laptop or Apple iPhone device, the captive portal works just fine. No certificate warnings or issue's. If we try a (random) Android device, we get two certificate warnings about not being able to verify the certificate. If we click on advanced, continue, the portal gets shown. 

We have investigated this issue ourselfs. To us, it seems like Android doesn't trust the (Root-)CA of the wildcard certificate by default, while Windows / Apple devices do. 

We tried to upload the full chain by performing the following steps: 

1. Connecting to the Guest WiFi as a client and opening the Captive Portal.
2. Saving the full chain as separate .cer files.

1. Dissect our wildcard.pfx to a wildcard.cer and wildcard.key
2. Combined all files into one .cer (like described here: https://community.arubanetworks.com/community-home/librarydocuments/viewdocument?DocumentKey=fcea273b-7b0f-43cd-b442-41d58022df1a&CommunityKey=39a6bdf4-2376-46f9-853a-49420d2d0caa&tab=librarydocuments).
3. Renamed the .cer file to .pem
4. Successfully uploaded the .pem to the Mobility Master (Managed Network > Configuration > System > Certificates) + the private key string of our wildcard.
5. Selected the new certificate as Captive Portal certificate (Managed Network > Configuration > System > More > General > Captive Portal Certificate).
6. Tested it with a random Android device > no luck, still the same certificate warning message.

Additional info:

We use the same wildcard / chain on other websites (e.g. XYZ.domain.com), that do get trusted by Android devices. We think the difference between the captive portal and the website is as follows: 

• Google Chrome / Microsoft Edge browser on Android does trust the certificate when browsing to website XYZ.domain.com. > Most likely used the build-in Chrome / Edge certificate trust list?
• Android built-in browser (automatically used when opening the Captive Portal) doesn't trust the certificate > Most likely uses OS certificate trust list.

We are using ArubaOS Software Version - 8.7.1.7. Anyone else experienced this issue before? 

Thanks in advance! 

------------------------------
Lex
------------------------------