Captive Portal not working on iOS devices only (DHCP 114)

[EDaleH]

@basharsaba

The "Your Connection is not Private" message in Chrome is telling you that your certificate used for Captive Portal does not have current data available or has no access to a certificate server. There are a number of tests you can do, just google the error and you will get a list.

The fact the error is in Chrome indicates you are hitting the captive portal and simply getting an SSL error message so nothing is wrong with the captive portal as long as the URL matches.

For older devices, use an http URL to test them, neverssl.com is a popular one. It frequently triggers the captive portal login page. If you get the certificate error above, it is a separate issue and as long as the URL matches the captive portal one, not a Captive Portal problem, as it proves you are being "captured".

You may want to ensure there are host overrides in your DNS Resolver for all SSL certificates used on Captive Portals. It doesn't hurt to add the certificate server DNS for your SSL certificate to the DNS list under System, General Setup either.

[Gertjan]

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

You may want to ensure there are host overrides in your DNS Resolver

Good catch.
If this is the URL used for the captive portal : "portal.bhf.tld" then this :

is important.

The host name "portal.bhf.tld" is resolved to the portal IP : (example) 192.168.10.1 and the portal web server should return a certificate that has a SAN that contains "portal.bhf.tld", and now the TLS (https) is ok, IF the certificate signer (CA) is recognized as 'valid' by the client's browser.

[Bisho]

@Gertjan Thank you for explaining RFC8910. Indeed, I didn't understand it which made me curious to read its history from this document RFC8910.
What you said about DHCP 114 requests by supported/unsupported devices makes total sense. If it's known to the device, it will use it and if not, it will neglect it.

@EDaleH Thank you for your input. The essential DNS Resolver part has already been done. I mentioned that in my previous reply Here

I tried to narrow down the issue, by focusing for now on the devices with Android 11 and above that understand and use DHCP 114 which keep getting the alerts "Your connection is not private" and "Turn on enhanced protection"...etc

iOS doesn't show these alerts because the default browser is Safari. Android's default browser is Chrome which is a bit annoying when it comes to securtiy and certificate validation.

Since I'm also getting the same alerts when I connect to the Captive Portal on my laptop using Chrome, I said if I could solve it on my laptop and make my connection to the Captive Portal page secure, then the new Android devices would have no issue and then I can focus on the old ones that don't understand DHCP 114.

I have done everything you could imagine on pfSense to make this connection secure and the only way that worked was by importing the ca_bundle.crt file to my laptop. By doing that, no more security alerts.

Obviously, this is not a feasible or practical solution when it comes to Laptops and Android phones in a hotel environment with hundreds of guests. I didn't even know how to import the CRT file to my Android phone.

My question. Have you heard of or seen any method to make the connection to a Captive Portal page secure through pfSense without importing any CRT file to the connecting device?

@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):

I know it works, as I can't control what devices people bring to my hotel. But they connect to my portal

This gives me some hope since I'm sure some of your guests are using Android phones but since you're not hearing any complaints, that means they are either not getting the alerts or they are getting the alerts but they know how to proceed.
It would be amazing if you could get your hand on an Android phone from one of your colleagues for example (or maybe from a nice guest) and see what they are seeing when they connect to your Captive Portal page. I'm just so curious.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

The "Your Connection is not Private" message in Chrome is telling you that your certificate used for Captive Portal does not have current data available or has no access to a certificate server. There are a number of tests you can do, just google the error and you will get a list.

I couldn't find any test. Any suggestion?

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

You may want to ensure there are host overrides in your DNS Resolver for all SSL certificates used on Captive Portals. It doesn't hurt to add the certificate server DNS for your SSL certificate to the DNS list under System, General Setup either.

I want to mention that my current TLS certificate is issued by Let's Encrypt. I also tried using one from ZeroSSL and it was the same issue.

What exactly are you asking me to do here? How do I get the DNS server of my certificate? Shall I get the IP of my portal domain https://portal.afxxxxx.com and add it somewhere? Or add the DNS server of the certificate issuer?

[EDaleH]

@basharsaba
One thing that catches my eye is your subdomain which is complex. portal.af.domain.com is more than one subdomain level. subdomain.domain.com is what you want here. I use Cloudflare simply because they provide first level subdomains free. If your registrar is giving you second level subdomains then you are likely fine as long as portal.af.domain.com is in the registrar's DNS server (pointing at captive portal vlan?'s IP) so the world can resolve it to that IP. Then you need to add that full domain path to the let's encrypt (ACME?) so it picks it up. ACME will not grab that level2.level1.domain.com until the next time you refresh the certificate. If you have done all that, then you are ready to test.

If it is working in iOS, it is not being resolved in Safari, it is the custom browser that is dedicated to logging onto captive portals that is being used for access. However, it does have to resolve the URL under SSL/TLS, i.e. the certificate must be valid. Are you using the same certificate URL for both iOS and android devices? This is important because if it is working on iOS with the identical path in the RFC8910.php file as captive portal uses (portal.af.domain.com:8003/index.php?xxx in your example) then you know the certificate and DNS are working correctly. They can not be different. Putting the correct URL into the DHCP114 option string for your iOS clients and having it work is proof you have the URL to the captive portal login page correct.

BTW, importing the certificate to the laptop simply proves it is not resolving either through DNS or the server that is the source of your ca_bundle.cert file. It sounds like you have a certificate file at the SSL Server that is not propagating, check that ACME is "picking it up" when it refreshes the certificate if that is how you are implementing it. ACME will pick up only a subset of subdomains if you don't include all of them in the list.
Now that you have the cert file on your laptop, you can no longer debug the problem on your laptop until you remove it.

So assuming no ca_bundle.cert file has been imported, take the exact URL you use in the RFC8910.php file and enter it into the URL of your chrome browser on your laptop. This is assuming it does not launch automatically when you connect to the AP that is serving that captive portal. If you have a DHCP address from the correct DHCP server for the captive portal, then entering the captive portal URL will launch the login screen. If you are already logged in, it will launch the "logout" screen instead (index.php does that for you). We use the logout screen as a dashboard to report the status of the connection to the portal (typically time and bytes). If you haven't written a custom one, you will just get the logout screen. What you should not get is an SSL error or not found related error.

Normally, if the certificate were invalid, you would not be logging into iOS either, it too gives a security related error, but I believe it is something like "a secure connection is required".

As long as the error is SSL related, you do not have a captive portal problem. DNS, the company providing the certificate, and if used, ACME are where to concentrate on troubleshooting it. BTW, if you have the certificate info for the URL (subdomain.domain.com) in the DNS resolver but not in the DNS for the domain, then it will not resolve for the SSL verification, you need both for it to work.

[Bisho]

Thank you @EDaleH.

I believe you got confused about the URL because I was masking the domain name with asterisks. Anyway, it's not a secret.

So the domain URL is https://www.afamiahotelresort.com/ and the Captive Portal URL https://portal.afamiahotelresort.com/. So it's in the form of subdomain.domain.com or level1.domain.com which is correct, right?

The SSL/TLS certificates were issued for portal.afamiahotelresort.com. I mentioned that Here.

The RFC8910.php has this line:
$rfc8910_url = 'https://' . $_SERVER['HTTP_HOST'] . '/index.php?zone=' . $cpzone;

The DHCP 114 has this string:
"https://portal.afamiahotelresort.com:8003/rfc8910.php?zone=cpzone"

What is the Certificate URL? Isn't the above URL? If yes, then I'm using it for both iOS and Android devices. I don't even think there is an option to use different URLs for different devices.

I did remove the ca_bundle.crt file from my laptop, then I entered https://portal.afamiahotelresort.com:8003/rfc8910.php?zone=cpzone in Chrome and got the alerts with no secure connection (since I removed the cert file). I proceeded and got the login screen, I logged in and pasted the URL again and got the disconnect screen.

This is the General Setup and DNS Resolver options. I believe I'm missing the DNS Server IP and Hostname, right? What are they supposed to be? Whose IP or Hostname? Where do I get them from?

[Bisho]

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

This is the General Setup and DNS Resolver options. I believe I'm missing the DNS Server IP and Hostname, right? What are they supposed to be? Whose IP or Hostname? Where do I get them from?

I just tried to use 1.1.1.1 and 1.0.0.1 with Hostname one.one.one.one or 8.8.8.8 and 8.8.4.4 with Hostname dns.google but it didn't make any difference.
Do I need to get them from the certificate issuer (LE or ZeroSSL) or from the domain Registrar?

[EDaleH]

@basharsaba

Let's address these one at a time.

The first screen capture made it look like you had a period after the af which is now clear that you are using only a subdomain (1st level). That's good.

Your captive portal is on the LAN based on the IP assigned to it?. I have never built a portal on the LAN for security reasons so am unfamiliar with any consequences that may introduce.

You have named your captive portal "cpzone". That is unusual and confusing as apparently now $cpzone will resolve to cpzone in index.php. As stated before, go to Services, Captive Portal and make sure that the "Zone" column says cpzone for the zone name.

In order for your portal to work, I would set the DNS IP address to 192.168.1.1 given your internal captive portal requirements. If your device is using external DNS servers they will see:

Pinging portal.afamiahotelresort.com [10?.?6.??1.?0] with 32 bytes of data:
Reply from 10?.?6.??1.?0: bytes=32 time=65ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=63ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=63ms TTL=54
Reply from 10?.?6.??1.?0: bytes=32 time=65ms TTL=54

Ping statistics for 10?.?6.??1.?0:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 63ms, Maximum = 65ms, Average = 64ms

If they are using the internal DNS Resolver on 192.168.1.1 as DNS they will see 192.168.1.1 so there is a conflict right there. You can't control which DNS server resolves the address first. One reason the iOS may resolve it correctly is simply because iOS blocks internet access until after the captive portal authorizes access. That forces it to use the DNS resolver result on the default DNS of 192.168.1.1.

I suggest you dedicate subdomain "portal" to the captive portal and nothing else. Then edit your DNS provider records such that it points to 192.168.1.1. It is normal that afamiahotelresort.com would point to some other public IP, as would the www subdomain. Make sure you give it time to propagate the change throughout the internet, check the Time To Live value and wait that long at a minimum.

Your DNS question is not applicable as they all point to the wrong address for your captive portal. Thus they will never resolve correctly and I presume cause your certificate error message?

[Bisho]

Thank you @EDaleH for your prompt response.

My Captive Portal Zone's name is indeed cpzone. I kept it like that and modified the DHCP 114 String accordingly. I have tried different names and they all have led to the same issue.

I'm a bit in shock that the Captive Portal is supposed to be enabled on the WAN interface. To my understanding and from the many tutorials I have watched, clients get a DHCP lease from the LAN subnet and since the Captive Portal is enabled on the LAN interface the portal page will pop up, once they authenticate, they get internet through the WAN interface.

However, just for testing, I enabled it on WAN and the result was that no portal page popped up and I got internet access directly, which doesn't serve our purpose.

The portal.afamiahotelresort.com never existed before. We exclusively created it for the pfSense Captive Portal. a total dedication.

I set the DNS IP address to 192.168.1.1. Correct?

Now let's come to the tricky part. Correct me if I'm wrong. Are you asking me to set the DNS IP address to 192.168.1.1 in the domain's registrar which is NameSilo in my case? if yes, I doubt I can change the DNS record just for the subdomain URL. I will have to change it for the whole domain which might break everything. I will have to check but I thought to confirm with you first.

[EDaleH]

@basharsaba

No, never on the WAN. In my experience the captive portal is on OPT1, a third interface. A VLan is then defined if necessary for multiple captive portals. By placing the captive portal on OPT1, you can keep the LAN isolated through firewall rules for a local office or simply maintaining pfSense. You can set it up on the LAN, that is not your problem wrt the Certificate error.

I assume your response comes from not understanding why the subdomain portal.domain.com must point to the internal address of the Captive Portal. It seems you are confusing DNS with WAN. Yes, the DNS will point say a www subdomain to the public side of your WAN for a web site but the Captive Portal is on the inside of your firewall and it points to the non public address of the interface you assign it to. As you have it on LAN, 192.168.1.1, simply point portal.domain.com to that address. Do not change any of the other DNS entries as they have other purposes.

I think when you get the certificate error you may be resolving to the public address but to be sure, ping it from the laptop. For example. open a command prompt. Ping portal.afamiahotelresort.com. It should return 192.168.1.1. If it returns the public address then the captive portal is not there. That is an undefined state and it is no wonder the certificate is not valid.

Your pfSense host override should not change the address that the certificate is registered against as resolved by public DNS servers.

[Bisho]

Hi @EDaleH, I have some interesting updates.

So I went to the Registrar (NameSilo) and found that whoever developed the website www.afamiahotelresort.com, has set the NameServers (DNS Records) to be the Web Hosting company's ones. NameSilo clearly states that since we are not using their default DNS Records, then any changes we make will have no impact, so I left them untouched.

So I went to the cPanel which was the place where I created the subdomain portal.afamiahotelresort.com and got its SSL/TLS Certificate from LE.
There was no option to change its DNS Records, after talking to support, I was told that in order to do that, I needed to create a Dynamic DNS for this URL.
When I tried to do that, it gave me an error that the domain portal.afamiahotelresort.com already exists.

Since I didn't want to delete it from the domains, I went ahead and created a brand new URL called pfsense.afamiahotelresort.com and assigned it 192.168.1.1, and within minutes an SSL/TLS Certificate was automatically issued by LE. I checked its status and it was Validated.

I went ahead and did your suggested ping test. The weird part is that if my friend pings pfsense.afamiahotelresort.com from the hotel in his country, he gets a reply. If I ping it from home in the U.S., it shows 192.168.1.1 but I get timed out. We both used the DNS provided by the local ISP first, then set the DNS to 8.8.8.8 and 1.1.1.1 and It was the same result.
I will assume that pfsense.afamiahotelresort.com is resolving to 192.168.1.1 regardless of the ping reply. Shall I ?

I went ahead and changed all the configurations in pfSesne to pfsense.afamiahotelresort.com. Certificates, Domain, DNS Server Settings (IP and Hostname), Captive Portal HTTPS Options, DHCP 114, DNS Resolver Host Overrides...etc but unfortunately, the connection to the Captive Portal page was not secure.

I even enabled the option to Respond to incoming SSL/TLS queries from local clients, but it didn't have any impact.

I kept testing the Captive Portal page every 15 minutes, and then one time, I got a secure connection. No alerts or anything and the certificate was fully validated. I couldn't believe my eyes So I immediately grabbed my Android phone and tested but the connection was not secure.
I then reset Chrome settings and tried and I was back to square one. Connection is not secure until this moment.
I took a screenshot for the memory of the only time it worked.

It's driving me crazy.

[Bisho]

Another weird observation: My pfSense is virtualized. The VM Host that has 2 hardwired NICs (WAN to the ISP router & LAN to a WiFi AP) has no issue at all.
If I paste https://pfsense.afamiahotelresort.com:8003/index.php?zone=cpzone into Chrome or Edge, the connection is secure and the certificate is valid even after resetting both browsers several times. Note that their versions with my laptop are identical.

I'm getting the connection not secure when I connect my laptop or phone via WiFi.
To find out if it's an AP issue, I connected my laptop via cable to the pfSense LAN port (no more AP). I got a DHCP IP but I got the connection not secure. So the method of connection doesn't matter.
My laptop/phone and this VM Host use the same DNS and we both are on Windows 11 and no CRT file is installed.

Even the VM Host at my friend's hotel overseas is working without any issues as same as mine. I did several tests and the connection is secure and the certificate is valid !!!!

I really don't know what is special about these VM Hosts. They always accept the Certificate. Unlike clients (laptops/phones)

By the way, it's worth mentioning that even this working VM Host, does time out when pinging to pfsense.afamiahotelresort.com [192.168.1.1]. So getting a reply doesn't affect the certificate validation as long as the URL is resolving to the IP.

[EDaleH]

@basharsaba
Please take a break while I digest and understand your replies. I will be tied up for a day or so and will do my best to assist when sufficient time is available to review your replies in detail.

Please remember that any ping test outside your pfSense internal LAN will fail unless a local 192.168.1.1 actually exists. All you confirm is that the DNS entry is pointing to the same address that you associate with your Captive Portal. This is essential for the browser to associate the SSL certificate with the URL's DNS record and pfSense's certificate specified by the Captive Portal configuration..

[Bisho]

Please take your time. I'm already grateful for your help.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

Please remember that any ping test outside your pfSense internal LAN will fail unless a local 192.168.1.1 actually exists.

It makes total sense. In fact, when I'm on pfSense DHCP, the ping test to pfsense.afamiahotelresort.com [192.168.1.1] gets a reply.

@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):

All you confirm is that the DNS entry is pointing to the same address that you associate with your Captive Portal. This is essential for the browser to associate the SSL certificate with the URL's DNS record and pfSense's certificate specified by the Captive Portal configuration

All Confirmed. Otherwise, the VM Hosts at both locations wouldn't work and get a secure connection with a valid certificate as I explained above.

[Gertjan]

@basharsaba

The certificate you use contains the (only) 'SAN' : "pfsense.af####.com"
It should also contain "portal.af####.com".

Again, the portal URL is "portal.af####.com" so the certificate should contain "portal.af####.com".

I agree with @EDaleH : a portal should be on it's own LAN type interface like OPTx - but not LAN - or WAN. But ... it does work when you use LAN.

[Bisho]

@Gertjan
I'm using now a new URL pfsense.af####.com with a new certificate that only contains pfsense.af####.com and pointing to 192.168.1.1 (Dynamic DNS) and all the configuration has been changed according to this new URL. Why would I still need the old URL portal.af####.com ?? In fact, I can do that, but I know it will lead to the same issue.

I can work on OPTx later. For the time being, let's keep it on LAN. The most important and mysterious question is why both VM Hosts at both locations are getting a secure connection with a valid certificate, unlike any connected device.

[EDaleH]

@basharsaba
Let’s review the pre-requisites within pfSense besides the setup under Captive Portal.

Under System, Certificate, Authorities you must have a Certificate Authority for your certificate and it must contain a current copy of the Certificate data. Either ACME is taking care of that for you or you are pasting the Certificate Data into the box with that label. Note the “Name” of that external issuer. Under the Certificates column of Certificate Authorities you will see at least the number 1 for quantity, that is the certificate for the portal.

So, go to System, Certificate, Certificates and in the name column you will see your domain name listed. The Issuer will match the “Name” in the above. In the “In Use” column you should see at least Captive Portal DNS Resolver and possibly Acme(1) if you are using ACME to renew your certificate.

If you have not updated the certificate data above after adding a subdomain to the certificate, it won’t work because the SAN list (Subject Alternative Name) does not contain the subdomain you pointed the captive portal at. Thus, certificate error.

Now that covers the certificate, how does the browser find the Captive Portal?

You are now familiar with the URL required to launch the login page to get through the captive portal. You can force this page to load in a browser tab by either having the Captive Portal capture your attempt to go to an http site, by entering the portal url directly into the browser URL or by using RFC8910’s DHCP114 to send the URL to an aware device that will typically launch a custom browser to load that page directly without being “captured and redirected to it”. What the browser is and how it got that URL entered is no longer important. Now the browser processes the request.

Well, it needs to find out where that domain is so it does a DNS query and gets an IP which is the IP of the Captive Portal, 192.168.1.1 in your example.

As this is an ssl request, it retrieves the public SSL key and it is the job of pfSense to handle the private key. If there is a subdomain like portal.domain.com, the “portal” subdomain must exist in the SAN list of the certificate and it provides the IP address as it also must exist in the DNS for the domain. If there is a discrepancy in any of the above, you get a browser specific SSL certificate error. You can look it up in edge by clicking the lock icon, then details, then Certificate Subject Alternative Name. Below is an example for gmail.com: Note accounts.google.com and *.partner.android.com are SANs

For me, the introduction of Dynamic DNS, VM, etc is just a lot of noise to distract you from the final objective. When you have the error on the laptop, drill into the certificate data by clicking on the square icon with the upper right arrow.

and try to figure out what is offside. If you get a successful connection, also verify the SAN list.

You need to identify what is failing and ensure the pfSense certificate data is current. The browser should tell you why it failed.

[Gertjan]

@basharsaba

Because : You should (I really advice you to do so) :

== remove "portal." in front of the domain name. It doesn't belong their.

This pfSEnse.af#######sort.com has IP 192.168.1.1 - that's your LAN host name pfSEnse network name.
Now you can access pfSense using pfSEnse.af#######sort.com from LAN.

Then : go her :

and I presume that your captive portal IP is 192.168.2.1.

Remember to set up the captive portal DHCP server - pool for example 192.168.2.10 -> 192.168.2.254.

For starters : set up a generic pass all fire wall rule on the Portal interface.

Check that unbound listens on the portal interface.

If you need certs, and you use acme.sh : ask for two (yeah,n why not) certs :
One for pfSEnse.af#######sort.com - use this one for the pfSense GUI
One for portal.af#######sort.com - use this one on the captive portals setup page.

From now on, when a DNS request for "portal.af#######sort.com" comes in (pfSense), it will answer "192.168.2.1" !!
The portal web server will be contacted, and it will have a cert that says : I am "portal.af#######sort.com" => this is what https is all about.

Done.

Btw : Go here : https://www.youtube.com/@NetgateOfficial/videos and look for the 2 (3 ?) captive portal videos.
There are old.
But still very valid.

[Bisho]

Hello Gentlemen,

Let me answer your questions one by one.

@EDaleH

My certificate is automatically issued by LE and to my understanding LE is one of the most popular ACME Certificate Authorities. However, the System/Certificate/Authorities section in my pfSsens is blank. Do I still need to create a CA Authroty? if yes, how? what method? Internal, intermediate, or import?

The Certificate is imported correctly and validated for the URL pfsense.afamiahotelresort.com and the "In Use" column is exactly as you described.
The SAN list does contain DNS Name: pfsense.afamiahotelresort.com

I also compared every single field in the Certificate Details between my laptop (with no secure connection) and the VM Host (with a secure connection) and they are all identical. I couldn't find anything offside on my laptop.

@Gertjan

Just to recap. I'm no longer using the portal.afamiahotelresort.com nor 192,168.2.1. It's now pfsense.afamiahotelresort.com that has a Dynamic DNS resolving to 192.168.1.1 which is already added in the Host Overrides.
So to rephrase what you said: From now on, when a DNS request for pfsense.afamiahotelresort.com comes in (pfSense), it will answer 192.168.1.1

[Gertjan]

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

... However, the System/Certificate/Authorities section in my pfSsens is blank. Do I still need to create a CA Authroty? if yes, how? what method? Internal, intermediate, or import?

I use the pfSense acme.sh package also.
It will also populate the System > Certificate > Authorities "CA" page :

Note : some of them are old, and I should remove them.
AFAIK, when a web server serves a cert to a web browser, it will create a cert chain : CA, intermediate and the cert itself. It send the entire chain to the browser. If the CA is missing, that could very well explain your https error.

My browser shows the chain :

So ISRG Root X1 signs R10 signs my domain (wildcard) certificate.

Btw :

is probably not need as you have also this :

Check for yourself : look at your /etc/hosts file : you have "pfsense.afamiahotelresort.com = 192.168.1.1" now twice.

[EDaleH]

@basharsaba said in Captive Portal not working on iOS devices only (DHCP 114):

I also compared every single field in the Certificate Details between my laptop (with no secure connection) and the VM Host (with a secure connection) and they are all identical. I couldn't find anything offside on my laptop.

Your certificate is "afamiahotelresort.com", that is what it should say in the name column. It simply will not work the way it is because it is currently looking for a second level domain as in: pfsense.portal.afamiahotelresort.com which you don't have.

Below is what a typical multi portal Captive Portal setup SAN certificate chain might look like for example:

DNS Name: domain.com
DNS Name: free.domain.com
DNS Name: day.domain.com
DNS Name: week.domain.com
DNS Name: month.domain.com
DNS Name: data.domain.com
DNS Name: somethingelse.domain.com
DNS Name: pfsense.domain.com
DNS Name: security.domain.com

Each would typically point to a different IP unless you use two different URLs to access the same page. domain.com and pfsense.domain.com could both point to the webconfigurator on 192.168.1.1. and security.domain.com could be a Network Video Recorder on 192.168.1.253 with free.domain.com on a Captive portal which is on VLan10 on 192.168.10.1 which is associated with interface OPT1 as a VLan under interfaces, the same for the rest, all on different VLans/IP ranges. Each will need DHCP, a firewall rule and DNS setup to function. If you are using VLans you will need Level 2 switches that support 802.1Q. The assumption in this thread has been that you are doing everything on the LAN, which is assumed to be on 192.168.1.1/24. Gertjan's responses assume you associated a VLan on 192.168.2.1 which is entirely valid but DIFFERENT. Your Captive Portal IP's DHCP Server must match be supplying an address in the same range(subnet) as the the DNS IP specified in the domain registration for subdomain.domain.com (pfsense.afamiahotelresort.com) in your case.

There will be an external Certificate Authority for domain.com (just the domain name, no subdomain, i.e. only one period before .com, no more periods). Under System, Certificate, Authorities you should see something like:

Acmecert: O=Internet Security
Research Group, CN=ISRG Root X1, C=US external

Under System, Certificate, Certificates you will have one entry for just that domain.com, no subdomains, i.e. only one period before .com

Name:
domain.com
CA: No
Server: Yes

Issuer:
Acmecert: O=Let's Encrypt, CN=R11, C=US CN=domain.com
Valid From: Thu, 18 Jul 2024 02:31:26 -0400
Valid Until: Wed, 16 Oct 2024 02:31:25 -0400

In Use:
webConfigurator Captive Portal DNS Resolver
Acme (1)

The only place you enter your subdomain name(s) is in the captive portal and DNS Host overrides, everything else is referring to the primary domain exclusively.

Below is a DHCP screenshot of a setup similar to what I described above:

If you are working with just the LAN, you will only see WAN and LAN on your setup. The remainder are all related to L2 VLans, the first being the interface and the remainder the VLans assigned to that interface. Each of them has their own Captive Portal and DHCP assisgned to them.

So you have only one LAN, one DHCP server on the LAN and thus a Captive Portal running on the LAN subnet 192.168.1.1/24 (pfSense default setup address assumed)

Bottom Line: My suggestion is that you have not registered your certificate correctly. That certificate should be afamiahotelresort.com

When I check your certificate two interesting things show up. It is not Trusted and it appears to have a wildcard SAN *.afamiahotelresort.com indicating you can add any subdomain in front of afamiahotelresort.com? This is the certificate foundation upon which you have built your configuration.

and

The certificate is not signed !! My Mcafee will not permit me to look at www.afamiahotelresort.com, it pops up a "Suspicious" error.

If you are working with an existing domain that serves your website and trying to add in a captive portal, you have many additional variables to deal with. I would suggest a new domain name that supports single level subdomains for free. Cloudflare is one example for $10 or so a year. Well worth the simplicity it adds. Let your web designer and ISP play with your web site, take control of your Captive Portal by using a dedicated domain/ACME setup, likely with a 90 day free let's encrypt certificate. I am confused though that you seem to be maintaining the afamiahotelresort.com certificate yourself (ACME/pfSense), did you by any chance override the original registration? It looks like a wildcard certificate and they are expensive.