SSL warning for a valid certificate with captive portal login

UNAP · ‎04-10-2018

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 · ‎04-10-2018

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 · ‎04-18-2018

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

emnoc · ‎04-19-2018

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

emnoc · ‎04-18-2018

It could be browser cache of the SSLcertificate , I would also advise to flush all browser items and even private-tab to validate

e.g

chrome-about internal-nets

delete all firefox HSTS/PKP etc...

Test with curl and to something simple { https://www.example.com or badssl.com }

I'm sure curl will display any certificate issues and at least show you want cert-chain is present.

PCNSE

NSE

StrongSwan

UNAP · ‎04-19-2018

Fishbone wrote:
Maybe you have missed my response.

yes I did, sorry.

Ok I did try curl (good advise by the way) and this is the output.

~$ curl -v www.google.cl
* Rebuilt URL to: www.google.cl/
*   Trying 64.233.186.94...
* TCP_NODELAY set
* Connected to www.google.cl (64.233.186.94) port 80 (#0)
> GET / HTTP/1.1
> Host: www.google.cl
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 303 See Other
< Location: https://fap-cp-test.unap.cl:1003/fgtauth?05060c9eb8bb0ce5
< Connection: close
< Content-Length: 232
< Cache-Control: no-cache
< Content-Type: text/html
<
* Closing connection 0
<html><head><title>Firewall Authentication</title></head><body>Redirected to the secure channel.<a href="https://fap-cp-test.unap.cl:1003/fgtauth?05060c9eb8bb0ce5">Click here</a> to load the secure authentication page.</body></html>dpacheco@unico-47:~$

~$ curl -v https://fap-cp-test.unap.cl:1003/fgtauth?05060c9eb8bb0ce5
*   Trying 10.39.228.1...
* TCP_NODELAY set
* Connected to fap-cp-test.unap.cl (10.39.228.1) port 1003 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

and as it can be seen, there is a problem with the certificate, but I'm note quite sure what could be, because this certificate is the same used for Fortigate web admin interface, and there is no problem with chromo or other browers (no certificate warning).