Captive portal and certificates

[Storyteller]

Today, without doing anything my captive portals does not work anymore.

Both IE and Chrome give me a message about wrong certificate but after I force a reconnect I cannot access to login page. 

The page seems expired (I think it is really expired because of IE and Chrome reconnection).

With Firefox I can add the exception and after that it works.

I suppose that IE and Chrome stops the session thinking about a Man in the Middle attack and ask me for a confirm. When I confirm they reload the page but the Captive portal session is meantime expired and the page is not reachable.

With Chrome if I try to open a HTTP site without HSTS it works (no man in the middle detection).

My two captive portals work on two private network 10.40.... and 10. 41.... and the portal is in these LAN. How can I solve my problem? I assume the computers connected being guest computer without chance to install some certificate or private CA auth. 

Graziano.

[leif_erikson]

We also have the same problem, so many users are complaining. Does anyone have a solution to this?

FG-500D v5.2.3,build670 (GA)

[Storyteller]

In IE I must insert the site in trusted site and after several attempts (restarting IE) it shows me login page. Then I can login.

But this is a workaround...

Regards,

Graziano.

[Fishbone_FTNT]

Hi all,

somehow I missed this thread. Chrome (and I suppose also others will be following) started to require SAN DNS in certificate for hostname check. In older releases, you can add your own certificate in auth portal (with correct FQDN in cert DNS SAN), or you can use 5.6.x, which will generate auth portal certificate on its own.

Do a simple check: see details of untrusted certificate. If it's missing Subject Alternative Name DNS which matches your auth portal FQDN, then it's this what I am talking about.

Regards,

 Fishbone)(

[Storyteller]

Hi Fishbone,

I don't have any FQDN for guest LAN because I cannot access any internal DNS to resolve it. I have setted up two LAN 10.40.X.X and 10.41.0.0 and the client try to connect to 10.40/1.0.1:1003 to authenticate. 

The certificates with problems seems to be CA CN=support. The message of Chrome is:

"This CA Root certificates is not trusted because it is not in the trusted root certification Auth store."

After I add it in the Trusted store the browsers tells me the certificates has problem because the hostname differs from website.

But I need this Wifi for Guest. I cannot ask to him to install CA certificate before to connect. I cannot make guest client to connect to my LAN in order to verify the CA. 

Do I have to install a real certificates with host-name as the ip?

And can I link to different captive portals in different LAN?

Regards,

Graziano.

[Fishbone_FTNT]

Hi Graziano,

guest access... you can't ask folks to install your CA as trusted CA, that's clear. In that case you can't redirect HTTPS internet connection attempts to portal without certificate warning, because the redirection must be inspected, and replaced with redirection to your portal.

I am afraid there is no perfect solution to this.

What you can do is to prevent Fortigate to touch HTTPS at all. You can remove https from:

config user setting     set auth-type http https ftp telnet end

... but this will affect whole VDOM.

Alternatively, you can create a new VDOM for guests, and make this change there. Result will be guest timeouts on attempts to access https internet, but it will redirect to portal plain unencrypted http. Not nice, but alternative approach without cert warnings.

Once redirected to portal, you need to trust the HTTPS site (you can use plaintext logon portal, but I guess you don't want it). Because the redirection to IP address would require IP address in certificate and no commercial CA would issue certificate with private IP in SAN, I suggest to: - allow DNS for guests (you can have DNS server on Fortigate, too)

- register some DNS domain with suitable name

- create some A record with suitable name pointing to your private IP address to portal

- buy certificate for that A record FQDN

- install this certificate into Fortigate and use it for portal

=>

Guest access:

1/ https is silent for unauth guests

2/ http access will be redirected to https portal, without cert warnings

3/ guest authenticates

4/ https (and overall internet access) will start to work according to your policies

As I said, not perfect, but for someone better than to see cert warnings. Matter of taste and preference...

hth,

 Fishbone)(

[Storyteller]

What you can do is to prevent Fortigate to touch HTTPS at all. You can remove https from: config user setting     set auth-type http https ftp telnet end ... but this will affect whole VDOM.

This solution satisfies me because I have no other user auth in my LAN. Only this for Guest Wifi LANs.

Thanks.

Regards,

Graziano.

[emnoc]

Purchase a trusted certificate or build a Enterprise level  PKI on the CN and ALtName  most if not every browser is NOT looking at the CN if the AltName is present as said earlier you need to be aware  of this.

http://socpuppet.blogspot.com/2017/11/cn-and-subject-alternative-names-in.html

The problem in the op  is really at the web-browser and security level. Deploying a proper certificate that's trusted will fix your issues and ensure it's in your trusted store.

[boneyard]

i don't fully agree. yes for the eventual page a good certificate helps solving that message.

but for the initial redirect on HTTPS requests there is no solution. you can't provide the correct certificate for the https://www.google.com request which get then redirected to the captive portal page.

you agree emnoc?

it would help if FortiGate would document this well. it isn't there fault or issue, this is just how SSL is supposed to work.

[sbuerger]

boneyard wrote:

but for the initial redirect on HTTPS requests there is no solution. you can't provide the correct certificate for the https://www.google.com request which get then redirected to the captive portal page.

Is there a way to simply disable the https -> https redirect?

So we get a [link]http://www.google.de[/link] -> [link]https://captiveportalloginpage[/link] without warnings and for [link]https://www.google.de[/link] it just does not connect until the user ist authenticated?