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

[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.

[Gertjan]

Added to what @EDaleH said :

I rent a domain domain name, #######.hotel-fumel.net that I solely use for my pfSense LAN networks(s). (LAN, Portal, DMZ, etc.)

I also have the #######.hotel-fumel.fr domain that is used for the hotel's web site. This domain is accessible and usable "on the Internet" for the public.

My #######.hotel-fumel.net - when used on the Internet, points to nothing .....shuuut, don't tell anyone : my IPv4 ISP WAN IP. Which is actually a pfSense network ^^

Right now, I guess your host ? - or you, get a wild card certificate to be used on the public web server.
And locally, with pfSense, the acme.sh package, you also get a certificate using the same domain.
That's ... Ok, I guess.

My acme.sh setup :

which is the 'wild card' setup - the certificate I get back from Letsencrypt :

And now I can use this certificate for all GUI web interfaces on my LAN network for the devices that have a web GUI :
printer1.#######.hotel-fumel.net set with a DHCP MAC Lease
synology1.#######.hotel-fumel.net set with a DHCP MAC Lease
Airco.#######.hotel-fumel.net set with a DHCP MAC Lease
and also
pfSense.#######.hotel-fumel.net = 192.168.1.1 set in the pfSense GUI.
and
portal.#######.hotel-fumel.net = 192.168.2.1 set with a resolver host override.

VLAN : I'll use them as soon as I have some spare time, so I can safely abandon the Keep It Simple principle. It should work, though, when set up correctly (sic).

Extra - totally not related : : http://www.afamiah#telresort.com/welcome/ shouldn't really exist anymore. http is ok, and should do just one thing : redirecting to https:// Typically this is done as early as possible, in the web server config.
For me, this domain name (web site), the https part, had no certificate errors ....

[EDaleH]

@Gertjan
The status of the certificate changes with different ssl checkers. Only sslchecker.com fails it, ssl.com gives it a clean bill of health. It is curious that one checker fails it though.

The certificate is a wild card certificate.

• this is great because you can create any single level domain name you want without any further work. Despite that, read on.

The certificate authority does not exist in pfSense System, Certificates, Authorities?

•  - Is this a serious problem, I am unsure but I think so.  Normally ACME handles that when you create the certificate but your certificate already existed?  The fact you have no Authority listed in pfSense is undefined and potentially a fatal flaw.
  

The certificate name in pfSense Syste, Certificates, Certificates has the subdomain?

•  - This is wrong as now you need to create pfsense.pfsense.afamiahotelresort.com in DNS.  and I am unsure if second level domains are supported in pfSense?
  

• It needs to be afamiahotelresort.com. That will permit the Dynamic DNS subdomain pfsense.afamiahotelresort.com to work with captive portal and DNS Resolver. Again though, read on.

You still need to have DNS resolve for pfsense.afamiahotelresort.com to the subnet you put the Captive Portal on -> LAN?, (assumed to be 192.168.1.1). This appears to be done.

Given all the above, I suggest a clean start that gives you complete control over the Captive Portal:

Advice: Buy a new domain that supports 1st level subdomains for your pfSense and Captive Portal. Be careful, most issuers do not support subdomains or charge a large fee for them. Cloudflare for one does not charge extra, I am sure there are others out there.

• Add DNS subdomains like portal, pfsense, and no subdomain at all.
• point pfsense at the webconfig address 192.168.1.1
• point portal at the Captive Portal DHCP Subnet, likely same 192.168.1.1.
• Setup ACME from scratch for the new certificate starting with Account Key, then configure the ACME certificate including all 1st level subdomain names and domain name without any subdomain.
• Setup DNS Resolver and Captive Portal for the new domain name and subdomains. Don't forget the firewall rule to allow internet access.
• test from the laptop.
• configure RFC8910 DHCP 114 support for the new domain name and test devices that support it.

[Bisho]

Hello @EDaleH and @Gertjan,

I went through all your notes and advice, I have no problem getting a new/dedicated domain from Cloudflare, but I feel I'm very close to achieving what I want using the existing domain. Let Cloudflare be the last resort.

Out of curiosity, I went to a hotel nearby today where my laptop and Android device always get a secure connection and checked their Captive Portal certificate details, then applied what you guys suggested and compared it to this hotel's Captive Portal certificate that uses 2 SANs. One is the domain and one is the wildcard domain. Their URL also resolves to an internal IP. Here is a screenshot.

And here is mine

Anyway, I started from scratch, but when I was doing the Acme Certificate options, I didn't know what to put in the Server, Key, Key Name, and Algorithm. I appreciate your advice.
By the way. I used the LE's Production ACME V2 to register the ACME account key.

Also, I got an error when I tried to issue/renew the certificate. Is there anything I need to do from the domain/registrar's side?

I also used afamiahotelresort.com for the Certificate's Common Name.

[Gertjan]

@basharsaba

You saw the difference ?

and

Btw :

update fail.
If you want more details : see the "more details".

As you can see, the "CA" is also available. and afaik 'acme' would have stored it in the CA list if it is missing.
You know where it is, you could place it in there manually, if needed.

[Bisho]

@Gertjan,

Yes I saw the difference, Their Certification Hierarchy starts with a Certificate Authority which I'm missing.

In my particular situation, where am I supposed to create the Certificate Authority? Under System/Certificate/Authorities? If yes, Internal, intermediate, or import?

Or under ACME Certificates? What about the Key fields?

Here is the acme_issuecert.log.txt It's tooooooooo long and confusing. I couldn't spot the exact issue.