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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
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
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
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:Hi, I'm actually using same config or both wired and wireless guest....
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.
...
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
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 ?
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
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
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.
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.
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
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1692 | |
1087 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.