Captive portal authentication over TLS

[GSA_George]

Hi, I've enabled captive portal on our systems, following the PA docs (Configure Authentication Portal (paloaltonetworks.com)). I have an SSL/TLS profile created with a valid, trusted certificate signed by our own internal CA. When our machines try to authenticate to the captive portal, they do so over HTTP not HTTPS. Is there some way to force captive portal auth over HTTPS? 

Thanks!

[S.Cantwell]

Hmmm, good question.  The SSL request needs to come from the users browser, not from the FW. 

You may want to also make sure that your redirect IP has an interface mgmt profile that support only HTTPS and not HTTP.

You may want to confirm that traffic from the user to the redirect IP is ONLY SSL on app-default, vs any on port 443.

Thanks.

[GSA_George]

Hi Steve,

The SSL request made to the firewall is via a 302 injected into the session by the FW. If I decrypt the traffic I see the 302 which has a header location value of http://my_captive_portal_addr:6080.

Palo alto documentation suggests that 6080 should only be used for NTLM auth (Ports Used for Management Functions (paloaltonetworks.com)) however we are successfully auth'ing using kerberos. 

If  I manually browse to https://my_captive_portal_addr:6082 I get a valid TLS connection albeit with a 403, so the firewall is obviously capable of setting up a TLS encrypted session to the captive portal address. 

The interface management profile I'm using doesn't have HTTP or HTTPS selected. Only Response Pages and User-ID, which I believe is suggested by the palo alto documentation. I'm having a bit of trouble getting logs for the traffic in question, although I can see it in the fw session browser, I'm not sure it's using the security rule I'm expecting, so I need to narrow that down first.

I was hoping there might be a way to tell the captive portal configuration to only use port 6082 but my googling has returned nothing so far. I can't see that configuring a security rule allowing only SSL on app default will make any difference given the header location specifies http traffic over port 6080.

Thanks,

George

[jambulo]

Anyone have a solution to this problem? I'm seeing the exact same thing.  I verified via PCAP that users are getting redirected to the Captive Portal unencrypted over port 6080.  I can browse to the Captive Portal over port 6082 and I get a valid TLS connection with the correct server certificate.

[rmeddane]

@jambulo @GSA_George @S.Cantwell  I was faced to the same issue and I found where is the problem :

If you are using the IP address of the firewall or the FQDN in the Authentication Portal Settings, make sure that the certificate associated to the TLS Service Profile has this IP address of the FQDN in the SAN (Subject Alternative Name).

[S.Cantwell]

Hello @rmeddane 

Thanks for this info.. I totally make sense that if the cert is signed as FDQN, then we use the FQDN name, but if the cert is signed by IP, then we use the IP in the Captive Portal settings... same/similar to a local/test GP configuration. 

It is good info for other community users and your contribution is appreciated.

[rmeddane]

Thanks @S.Cantwell  for the additional infos.