Captive Portal certificate issues

rm

went through the cert chain and added any domain urls I could find. We'll see if it helps.

Derelict

@rm If they are requiring OCSP then you have to be sure all of the addresses necessary to perform that are reachable pre-auth. Your certificate should contain everything you need to find the hostnames/addresses.

Gertjan

@rm said in Captive Portal certificate issues:

These devices are configured to not allow the users to proceed with a bad cert and the warning page.

That's the default browser behaviour these days.

@rm said in Captive Portal certificate issues:

We are using a captive portal with an external SSL certificate

What is an "external certificate" ?

@rm said in Captive Portal certificate issues:

but the certificate is being flagged since the endpoints cannot reach the external CAs to verify.

If you use a certificate with the OSCP option set, then the browser could take the decision that it should do the steps for validating - this means : it will contact the OSCP servers.

This means you've created a "chicken and egg" problem.

The user needs an Internet access and is behind a captive portal.
The user (device) visits the portal, it has a certifciate.
The browser is told by the certificate to do OSCP. That's Ok => jump to 1)

Solution : use a cert without the OSCP flag.

edit :
After all, the certificate just facilitates the access to the login page. All browser want a valid 'https' these day, "http" is close to 'dead' now.
That's not a very important web page with private info etc. It's just a captive portal login page, no big deal.

Read What is OCSP Stapling? and you'll ask "what are the host names I have to add to the list" ?
You could get this info from the entitu that crated the cert you use.
And now, be carefull : this will not be a host name that points to an IPn, but many IP's.
Your captive portal firewall doesn't work with hos names, it converts them first an "IP". Chances are that the wrong (not all of them) IP's will get approved.
So again, security is fine, but a captive portal isn't like your not a 'bank' access. No OSCP needed for a portal.

rm

@derelict Is the proper spot to do this in allowed host names? I went through the cert authority chain and entered all the hostnames I could find.

rm

@gertjan Thanks for the reply, External as in 3rd party, public cert authority. Endpoints have strict security that we do not control. We can't change their behavior or install certs on them.
I added hostnames I could find in the cert chain but not sure if it works. I tried adding a test hostname but could not navigate to it. Is there a PFsense firewall change needed?

This problem has probably been around for awhile but now these endpoints are configured to not allow the browser to proceed with an unverified certificate. We cannot make any browser entries such as trusted sites and "thisissafe" is not working either.

rm

@gertjan Asking provider about OCSP flags. I don't have one of these endpoints available to test but thought they would need a CA to validate, always thought it was a browser/OS driven setting and not a certificate one. I'll see what they come back with.

Derelict

@rm it depends on whether that is good enough to add all the IP addresses necessary. Experimentation will be necessary.

Gertjan

@rm said in Captive Portal certificate issues:

always thought it was a browser/OS driven setting and not a certificate one

Welcome to the club ;)

Read "What is OCSP Stapling? " and you start to understand what it actually is/does.
Or pick one the very first OSCP hit from Youtube and you know 'enough'.

OSCP is fine for a classic web servers, like this one, my "test domain" that I use to fool around with.
Not for a "captive portal https web server front end page". See this as an exception to the rule.

Derelict

If the OCSP URL/location was not taken from one of the signed attributes in the certificate it would be worthless.

rm

@derelict I might be out of luck. "I'd like to mention that according to their team, the certificate can not be issued without OCSP."
The allowed hostnames area doesn't seem to work as I had hoped. Assumed these were hostnames (URLs) that would not be redirected to the captured portal. Seems like they still do. Any additional settings required?

rm

@rm I may have had a break through. MY test site seems accessible so hopefully the CA hosts above will be reachable on these endpoints. Will have to wait and see when one arives.

Gertjan

@rm said in Captive Portal certificate issues:

I might be out of luck.

You have a certificate, so you have( you rent ) a domain name.
Depending on the registrat you have, you can use the acme.sh pfSense package to obtain a domain name for your portal https access : no more need for Comodo, no more need to install the cert each year.

Let's say you domain name is "my-network.tld".
use acme to ask for a certificate with these two SANs :
pfsense.my-network.tld
portal.my-network.tld

Now you can use this cert for the GUI access, and the captive portal access.
I presume you access your captive portal from 192.168.2.0/24 and this interface will got grant access to the pfSEnse GUI. A captive portal 'should' be using its won interface, and this should not be LAN ( It is possible, true )
The standard LAN 192.168.1.0/24 has access to the pfSEnse GUI.

Un check OCSP stapling ( before you request a cart ) and issue solved.

@rm said in Captive Portal certificate issues:

MY test site seems accessible so hopefully the CA hosts above will be reachable

Be careful. OSCP requests from a browser are cached by the browser. So when it seems to work, the info used was available locally. When the cache times out, the request is made again.