Security

Two part question. 

1. When using a wildcard certificate on the controller for a clean guest authentication workflow from CPPM (self-reg-> login). Do you need to only select the cert in the captive portal config item on the controller? Or, do you need to select it for the admin/webUI config item as well? I'm not 100% sure the difference. I would have assumed that the CP cert is just if you're going to use the controller's internal CP. 

 

2. Once that is done -- the NAS vendor in CPPM/guest just needs captiveportal-login.domain.tld ? This currently does resolve to the controller's IP.

 

I usually always have the customer setup a DNS A record just to ease things along, but it's not possible here. I'm getting weird redirection issues when using the 'custom' DNS name above (not 100% that's the issue) with and without the admin cert selected. Maybe I'm missing a simple checkbox? 

 

Just trying to rule out the obvious.

 

Thanks,

1. Just the captive portal certificate
2. Correct, but no DNS names are needed

Also, a wildcard is overkill, dollar wise. A standard single-name certificate (~$5 USD/year) is all that is needed for captive portal.

Thanks, Tim.

Yeah. I agree on the price. It's what I have, and since I can't mess with DNS, I guess I don't have much of a choice.

I usually buy a single name cert, set an A record and move on. . .

Was this changed in AOS 8.5.0.3? Client gets the message 'cannot reach this page' error after captive portal authentication. 

 

https://captiveportal-login.domain/cgi-bin/login

 

Do I need a A-record resolving this to an IP address and if so, what IP address needs to be resolved in a cluster? In the past there was no need for an A-record.

 

It has been a while using wildcards but I need to for this customer.

 

thanks

Erik

looks like it is changed. In stead of captiveportal-login.domain you have to use domain in AOS 8.5.0.3 

 

rgds,

 

Erik

 

Do you have any documentation for that change in 8.5.0.3? I’m not seeing anything related in the release notes, so is this a bug? We use a wildcard cert, so it assumes ‘captiveportal-login.xxx.yyy’. Are you saying it no longer redirects that FQDN?

No documentation found. I just experienced this on this customers project. I'm working with TAC because this must be a bug.

 

TAC states it should be captiveportal-login.domain

 

 I broke the internal CP functionality messing with the CP settings certificate to get Clearpass Guest working properly with the wildcard.

 

I opened the ticket because I kept getting the default certifcate sent to the client even when the GUI said the wildcard was in use. TAC collected data but couldn't fix it. I later found out you have to set the CP certificate on device level on both MM en MC. Higher up doesn't work (bug?). TAC states it should but they collected logs of it not working. I have also sent them logs of the internal Captive Portal working again.

 

When I got the internal CP working again, I noticed there was no hostname in de url. So I tried that on the Clearpass vendor settings and now Clearpass Guest works as expected. This must be a bug too.

 

It will prevend my customer to upgrade to 8.5.0.4 if thats the case though because that would break the guest wifi. I will have to leave instructions what to do if it is changed back to normal.

 

I'll keep this thread updated with input from TAC.

 

rgds,

Erik

 

It's  not a bug.

 

The provided certificate is not a standard wildcard certificate but a multidomain wildcard certificate. Ia: there are multiple wildcard domains added to the SAN. The subject therefore needs to be the domain; at least, this is how it was explained. 

 

The controller only checks the subject field where no * is found. So the Datapath FQDN is domain.

 

Hope this makes sence.

 

rgds,

Erik