SSL warning for a valid certificate with captive portal login

[UNAP]

Hi everyone.

So I set up a policy based captive portal authentication (not configured at interface level).  I forced HTTPS login page, assign an authentication certificate (a valid GlobalSign wildcard certificate for *.unap.cl) and set authentication redir-url.  Like this rule.

edit 77
        set uuid 1b9dfbee-18c8-51e8-b78f-0e0dacfd03c9
        set srcintf "IntRed-NoSegura"
        set dstintf "port17"
        set srcaddr "Red_10.39.204.0"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set groups "WiFI2"
        set comments "CP TEST - Salida Internet ENTEL"
        set global-label "Internet - DMZ - MPLS"
        set auth-cert "*.unap.cl"
        set auth-redirect-addr "fap-cp-test.unap.cl"
        set nat enable
next

It normally works fine witch Firefox web browser (tested under linux and windows), but with Chrome, Edge, IE and Android Web Browser I get the "unsafe site warning".

Really don't know why this happen and really don't know if is a Fortigate issue.

Pleas advise on where to look for solution.

Thanks

[Fishbone_FTNT · Accepted solution]

Hi UNAP,

if that works in FF, I assume redirection is setup properly from your side. Meaning you have properly set

config user setting

   set auth-ca-cert <SSL-inspect-CA-cert> end

If I am right, then the issue could be caused by the fact that Chrome (and possibly also others nowdays) require to have original site FQDN in SAN DNS name, in the cert which is present in the inspected connection redirecting traffic to the portal. FF still seems to not require this, Chrome started to require this some time ago (q4 2018 iirc). You can check actually, once you get cert warning. Display certificate and look for SANs. If the original site's FQDN is not there, it's likely the cause.

You would need to go for at least to upcoming 5.4 or 5.6 release to fix this. 5.2 is not planned to be fixed, if I look correctly.

6.0.1, 5.6.4 and 5.4.9 will contain the fix for issue I've described (tracked by our bug #0457883). Of course my advice is quite a guess, you would need to share with me more information to really be sure.

Fishbone)(

EDIT: fixed some html escaped garbage

[emnoc · Accepted solution]

Really don't know why this happen and really don't know if is a Fortigate issue.

if FF is not having issues and others are , than inspect the other browsers. In the mean time, have you  tried something neutral like curl

Please execute a curl -v  and display the  certificate chain

ken

[Fishbone_FTNT · Accepted solution]

Hi UNAP,

if that works in FF, I assume redirection is setup properly from your side. Meaning you have properly set

config user setting

   set auth-ca-cert <SSL-inspect-CA-cert> end

If I am right, then the issue could be caused by the fact that Chrome (and possibly also others nowdays) require to have original site FQDN in SAN DNS name, in the cert which is present in the inspected connection redirecting traffic to the portal. FF still seems to not require this, Chrome started to require this some time ago (q4 2018 iirc). You can check actually, once you get cert warning. Display certificate and look for SANs. If the original site's FQDN is not there, it's likely the cause.

You would need to go for at least to upcoming 5.4 or 5.6 release to fix this. 5.2 is not planned to be fixed, if I look correctly.

6.0.1, 5.6.4 and 5.4.9 will contain the fix for issue I've described (tracked by our bug #0457883). Of course my advice is quite a guess, you would need to share with me more information to really be sure.

Fishbone)(

EDIT: fixed some html escaped garbage

[Baptiste]

UNAP wrote:

Anyone? ... I still don't  know why just Firefox accept the certificate as valid.  At first I thought that is was using an old version of TLS (so some web browsers didn't accept it), but I can confirm that TLS 1.2 is used for transmission.

Is there any detailed documentation on how Fortigate capture traffic when captive portal authentication is enabled? I'm trying to analyze traffic with Wireshark, but there are behaviors that I don't understand.

Please, any advise will be aprreciated.

Fishbone wrote:

...

If I am right, then the issue could be caused by the fact that Chrome (and possibly also others nowdays) require to have original site FQDN in SAN DNS name, in the cert which is present in the inspected connection redirecting traffic to the portal. 

...

Hi, I'm actually using same config or both wired and wireless guest.

I think Fishbone is right : set your home page to a http site, you will be redirect without warning.

On wireless interface, most of times modern devices "see" there is a captive portal and ask you to authenticate before trying to access to your web site.

On wired interface, most of time Chrome, FF, Edge detect captive portal and add a banner that ask you if you want to be redirect. If not, you'll get a warning or an error page if HTST is enable

two examples

 

[UNAP]

Fishbone wrote:

Hi UNAP,

if that works in FF, I assume redirection is setup properly from your side. Meaning you have properly set

config user setting

   set auth-ca-cert <SSL-inspect-CA-cert> end

yes, correct SSL is set.

config user setting
    set auth-cert "*.unap.cl"
    set auth-secure-http enable
end

this certificate is a wildcard.

Fishbone wrote:

If I am right, then the issue could be caused by the fact that Chrome (and possibly also others nowdays) require to have original site FQDN in SAN DNS name, in the cert which is present in the inspected connection redirecting traffic to the portal. FF still seems to not require this, Chrome started to require this some time ago (q4 2018 iirc). You can check actually, once you get cert warning. Display certificate and look for SANs. If the original site's FQDN is not there, it's likely the cause.

You would need to go for at least to upcoming 5.4 or 5.6 release to fix this. 5.2 is not planned to be fixed, if I look correctly.

6.0.1, 5.6.4 and 5.4.9 will contain the fix for issue I've described (tracked by our bug #0457883). Of course my advice is quite a guess, you would need to share with me more information to really be sure.

Then solution should come updating fortigate firmware to 5.4 or 5.6 ?

[UNAP]

Fishbone wrote:

You can check actually, once you get cert warning. Display certificate and look for SANs. If the original site's FQDN is not there, it's likely the cause.

The original FQND won't be indicated, because is a wildcard certificate

[emnoc · Accepted solution]

So in the unap cert do you have the intermediates? What I would do from a curl  standpoint

Cat the  root/intemediates for the  issues and install into curl an into the windows ( assuming windows ) and then retest on windows and  the machine with curl

In  curl it these

CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs

IIRC cat the root/intermediate for issues and dump it into ca-certificate.crt 

example on macosx

cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt_ ; 

Cat the caroot and intermediates and then cat that biig file into the ca-certificates


cat mynewcaandintermediates >> /etc/ssl/certs/ca-certificates.crt ;

Then retest with curl? Does you warning go away ?

Ken
 

reference this https://superuser.com/que...authority-ca-to-ubuntu

[UNAP]

emnoc wrote:

So in the unap cert do you have the intermediates? What I would do from a curl  standpoint

I didn't add intermediate and root CA certificates to foritigate.  I added them according to this tutorial https://video.fortinet.com/video/159/installing-an-ssl-certificate-for-web-gui-access and now every web browser at any OS consider the login page as secure.

Thanks very much.

[UNAP]

Anyone? ... I still don't  know why just Firefox accept the certificate as valid.  At first I thought that is was using an old version of TLS (so some web browsers didn't accept it), but I can confirm that TLS 1.2 is used for transmission.

Is there any detailed documentation on how Fortigate capture traffic when captive portal authentication is enabled? I'm trying to analyze traffic with Wireshark, but there are behaviors that I don't understand.

Please, any advise will be aprreciated.

[emnoc · Accepted solution]

Really don't know why this happen and really don't know if is a Fortigate issue.

if FF is not having issues and others are , than inspect the other browsers. In the mean time, have you  tried something neutral like curl

Please execute a curl -v  and display the  certificate chain

ken

[Fishbone_FTNT]

UNAP wrote:

Anyone?

Maybe you have missed my response.  Please go back and try what I suggested ... + be more specific what you did an result/output of it. Curl is good way how to share cert with us, so we can help you.

Redirection works for TLS this way:

1. original session is SSL deep-inspected by CA configured here:

config user setting    set auth-ca-cert <SSL-inspect-CA-cert> end

Response is replaced and 30x code is retured with new location to Fortigate portal listening on tcp/1003 (by default).

Location is adjustable in 5.6 by

config firewall auth-portal    set portal-addr fgt.mynet.cl     # <<< FQDN - needs to be obviously resolvable by client end

2. the new connection is TLS, but to fortigate HTTPS server (fgt.mynet.cl:1003). So cert doesn't have to be spoofed (5.6 however does it)

3. tcp/1003 - Portal is displayed

4. tcp/1003 - user enters credentials

5. tcp/1003 - page is returned with javascript redirection. 

6. browser is accessing original website

The process of this can be described in more detail, but it's depending on FortiOS version.

It seems you don't want to share with us any details. If you really don't, please open a support ticket.

Fishbone)(