webauth portal for client with email consent not working-step by step

[jaheshkhan]

i have implement webauth portal for client with email consent enabled. but different devices response to page differently. some devices no issues with the page some dont get the first homepage to enter email id and some get page and after entering it wont show success paage. some of them get the success page with ok button. some people even after clicking ok button it wont respond. may I know the reason for these?

Can any body share step by step procedure for webauth portal for email consent. not need of entering credentials

WLC model - C9800-L-C-K9 (Cisco Catalyst 9800-L Wireless Controller )

Version - 17.3.4c

[balaji.bandi]

what device working what device not working, can you give more information of end device ?

since you did not mentioned what WLC, I take it as new Cat 9800 check below configuration guide can help you and customize:

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/216121-custom-web-authentication-on-catalyst-98.html

[jaheshkhan]

i have updated the details that i missed in main topic

WLC model - C9800-L-C-K9 (Cisco Catalyst 9800-L Wireless Controller )

Version - 17.3.4c

the link that you provided i already referred. im looking for workable step by step procedure for email consent web portal.

[balaji.bandi]

The URL provided a workable solution and worked when we tested, not artificially created.

Since you have a different issue not normal and also we do not what devices working and what not working, what you have done testing and debugging, what was your observation, it's hard to tell you what is the issue here.

As long as the steps follow, this works as expected, some setups are complex, especially routing and other stuff, where the redirect web portal is hosted.

So you need to debug related to your issue, or contact TACT

[jaheshkhan]

The link you provided is not related to email consent web portal.. its for web authentication portal.

Is there any step by step guide for email consent web portal. 

Devices connecting are android, iphone and windows machines.

[Rich R]

Start by updating your IOS-XE as per TAC recommended link below.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_vewlc_sec_webauth_cg.html

Remember many problems with portals are caused by not using proper public certificates which match the FQDN (domain name) of your portal with corresponding DNS for that domain.  If you're trying to do it with self-signed certificates then you're just wasting your time and your users' time.  If you use private certificates then they'll only work if you can configure trust of your private CA on every device.

[jaheshkhan]

I didnt understand you are pointing out. yes. currently we aer using self signed certificate. we are not using any FQDN in this environment. 

In my case authentication type im using is local web authentication.  its using internal default html pages. the ype of web authentication is consent or web passthrough.  so how certificate will play in this case? please let me know if im missing something.

[Rich R]

Any https page which must be displayed on a device uses a certificate.
The device must be able to trust the CA and intermediate that issue that certificate in order to display the page and content securely.
Modern devices and browsers mostly won't display the page and/or content (or sometimes only after dire security warnings and disclaimers) if they cannot trust the certifcate and that's why self signed certificates and using IP addresses instead of domain names causes problems.

If you insist on using self signed then you will have problems and you'll need to accept that (yes - the users will hate you for the rubbish service).
If you want it all to work properly then do it properly.

[jaheshkhan]

Sure. I'll consider this. And go for signed certificate. How about Microsoft CA internal certificate. Will it make any issue?

This is for guest.. So again Ms CA signed will. Be an issue??

[Rich R]

Correct - guest devices will not trust the internal CA certificate.

[Scott Fella]

Internal CA is good for 802.1x because devices joined to the domain will already trust that cert. a 3rd party cert is typically trusted by devices. You can always veryif that or ask the certificate vendor to make sure the root and intermediate are trusted by devices. Sometimes they will issue a certificate from a new intermediate CA that is not trusted on specific devices and users will still get a certificate error.

[Rich R]

As long as you load the full cert chain it should send the intermediate to the device (with the server cert) then as long as the device trusts the root the intermediate should be fine so new intermediate should not cause any problems.

[jaheshkhan]

sure. as per your advice ill consider public signed certificate. if they have existing wild card certificate can we use it in this case?

[Rich R]

I haven't tried wildcard myself but yes, in theory, that should work too.