Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
UNAP
New Contributor

SSL warning for a valid certificate with captive portal login

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

3 Solutions
Fishbone_FTNT

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

smithproxy hacker - www.smithproxy.org

View solution in original post

emnoc
Esteemed Contributor III

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

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
emnoc
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
11 REPLIES 11
Fishbone_FTNT

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

smithproxy hacker - www.smithproxy.org

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

 

2 FGT 100D  + FTK200

3 FGT 60E  FAZ VM  some FAP 210B/221C/223C/321C/421E

2 FGT 100D + FTK200 3 FGT 60E FAZ VM some FAP 210B/221C/223C/321C/421E
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
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
UNAP
New Contributor

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
New Contributor

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
Esteemed Contributor III

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

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
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)(

smithproxy hacker - www.smithproxy.org

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors