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

SSL Inspection problem

Hi all,

I have a Fortigate 90D with Web filter and SSL Inspection enabled.

 

I can't reach https://www.giustizia.it: with Chrome I receive "ERR_CONNECTION_CLOSED", with Firefox instead "Cannot create secure connection".

 

If I turn off SSL Inspection I can navigate to the site; I have tried to add an exception in web filter's rules (wildcard, simple, exempt, allow...) but with no luck.

 

How I can solve this issue?

Thanks in advance

5 Solutions
CÃ_sar_Romero

Jack_T wrote:

Hi, I have not exempts under SSL inspections options, maybe I have an old version of fortiOS? Thanks! :)

 

Exactly, this is available since FortiOS 5.2.

 

View solution in original post

CÃ_sar_Romero

If you don't want problems just follow the Upgrade Path available in the release notes (available at the version folder in support.fortinet.com). In that case you won't lose any configuration.

 

Regards.

View solution in original post

emnoc
Esteemed Contributor III

I  highly  doubt HSTS is the issue. What you could do is run a non browser http  tool like  curl or ab and see what happens.

 

As far as  a browser caching a "site" certificate, I never heard of that and that would break every concept of the PKI. Think about it, the  client still sends a hello, the server still send the certificate which has all of the goodies ( serial#, cry details, public-key, issuer,etc....)

 

 

Now back to the earlier, what does your  off browser diagnostic shows ( curl, gnutls,openssl,...) what's in the  cert-chain, are the  certificate trusted ?

 

I like using guntls-cli since it display all  certificates in the path and provides the final trust outcome.

 

e.g

 

macintosh:~ kfelix$ gnutls-cli www.wwt.com

Processed 214 CA certificate(s).

Resolving 'www.wwt.com'...

Connecting to '198.200.139.195:443'...

- Certificate type: X.509

- Got a certificate list of 2 certificates.

- Certificate[0] info:

 - subject `C=US,ST=Missouri,L=Maryland Heights,O=World Wide Technology Holding Co.\, Inc.,OU=IT Operations,CN=*.wwt.com', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust SSL CA - G3', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-02-10 00:00:00 UTC', expires `2017-05-11 23:59:59 UTC', SHA-1 fingerprint `c76d3b32cc494bef2f4950740ff94fb6e17e8fe9'

Public Key ID:

a8931554e42f5be923b093c0695a79f03e3e863e

Public key's random art:

+--[ RSA 2048]----+

|      .oo        |

|     . .         |

|    . . .        |

|   . = o . .     |

|    B * S +      |

|   + B + =       |

|  . +.* o o      |

|    Eooo . .     |

|   ..o..         |

+-----------------+

 

- Certificate[1] info:

 - subject `C=US,O=GeoTrust Inc.,CN=GeoTrust SSL CA - G3', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2013-11-05 21:36:50 UTC', expires `2022-05-20 21:36:50 UTC', SHA-1 fingerprint `5aeaee3f7f2a9449cebafeec68fdd184f20124a7'

- Status: The certificate is trusted. 

- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)

- Session ID: 92:C8:94:E2:E6:0D:09:C6:7B:90:00:24:4F:55:B0:4D:4A:B9:94:C1:60:DA:70:E6:98:2C:D0:AC:1E:E5:00:5F

- Ephemeral EC Diffie-Hellman parameters

 - Using curve: SECP256R1

 - Curve size: 256 bits

- Version: TLS1.2

- Key Exchange: ECDHE-RSA

- Server Signature: RSA-SHA256

- Cipher: AES-256-GCM

- MAC: AEAD

- Compression: NULL

- Options: safe renegotiation,

- Handshake was completed

 

- Simple Client Mode:

 

 

 

vrs a error

 

 

 

- Status: The certificate is NOT trusted. The name in the certificate does not match the expected. 

*** PKI verification of server certificate failed...

*** Fatal error: Error in the certificate.

*** Handshake has failed

GnuTLS error: Error in the certificate.

 

 

This will eliminate any funky thing with a browser and it's trust or policy, cache,etc.......

 

 

Use something like  ( gnu-tbs )  and follow the evidence, if you want to eliminate the FGT, set a fwpolicy b4 and to the site(s) in question and before and SSL intercept  fwpolicy

 

Don't make assumptions, don't  assume ,and follow the evidence.

 

;)

 

ken

 

 

 

 

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
emnoc
Esteemed Contributor III

Don't know about  window but do some  google search. On curl and SSL inspection, run  curl in  verbose mode and see what certs are shown

 

 

 

e.g

 

Macintosh:~ kfelix$ curl -v -k [link]https://www.giustizia.it:443[/link]

* Rebuilt URL to: [link]https://www.giustizia.it:443/[/link]

*   Trying 193.109.206.10...

* Connected to www.giustizia.it (193.109.206.10) port 443 (#0)

* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

* Server certificate: *.giustizia.it

* Server certificate: GeoTrust SSL CA - G3

* Server certificate: GeoTrust Global CA

> GET / HTTP/1.1

> Host: www.giustizia.it

> User-Agent: curl/7.43.0

> Accept: */*

< HTTP/1.1 301 Moved Permanently

< Server: nginx

< Date: Sun, 18 Sep 2016 03:40:42 GMT

< Content-Type: text/html

< Transfer-Encoding: chunked

< Connection: keep-alive

< Keep-Alive: timeout=20

< Location: [link]https://www.giustizia.it/giustizia[/link]

< X-Frame-Options: SAMEORIGIN

< X-Content-Type-Options: nosniff

< X-XSS-Protection: 1; mode=block

< X-Frame-Options: DENY

< Strict-Transport-Security: max-age=31536000; includeSubDomains

<html>

<head><title>301 Moved Permanently</title></head>

<body bgcolor="white">

<center><h1>301 Moved Permanently</h1></center>

<hr><center>nginx</center>

</body>

</html>

* Connection #0 to host www.giustizia.it left intact

 

Guntls provide more details and the certificate in the  chain.  if your inspecting MiTM, the ssl-proxy cert should be present and trusted.

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
creo
New Contributor II

hello,

turn scan all port for deep inspection, but not only 443. (And for certificate inspection too if you use it)

 

that works for me.

 

 

 

View solution in original post

27 REPLIES 27
emnoc
Esteemed Contributor III

I  highly  doubt HSTS is the issue. What you could do is run a non browser http  tool like  curl or ab and see what happens.

 

As far as  a browser caching a "site" certificate, I never heard of that and that would break every concept of the PKI. Think about it, the  client still sends a hello, the server still send the certificate which has all of the goodies ( serial#, cry details, public-key, issuer,etc....)

 

 

Now back to the earlier, what does your  off browser diagnostic shows ( curl, gnutls,openssl,...) what's in the  cert-chain, are the  certificate trusted ?

 

I like using guntls-cli since it display all  certificates in the path and provides the final trust outcome.

 

e.g

 

macintosh:~ kfelix$ gnutls-cli www.wwt.com

Processed 214 CA certificate(s).

Resolving 'www.wwt.com'...

Connecting to '198.200.139.195:443'...

- Certificate type: X.509

- Got a certificate list of 2 certificates.

- Certificate[0] info:

 - subject `C=US,ST=Missouri,L=Maryland Heights,O=World Wide Technology Holding Co.\, Inc.,OU=IT Operations,CN=*.wwt.com', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust SSL CA - G3', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-02-10 00:00:00 UTC', expires `2017-05-11 23:59:59 UTC', SHA-1 fingerprint `c76d3b32cc494bef2f4950740ff94fb6e17e8fe9'

Public Key ID:

a8931554e42f5be923b093c0695a79f03e3e863e

Public key's random art:

+--[ RSA 2048]----+

|      .oo        |

|     . .         |

|    . . .        |

|   . = o . .     |

|    B * S +      |

|   + B + =       |

|  . +.* o o      |

|    Eooo . .     |

|   ..o..         |

+-----------------+

 

- Certificate[1] info:

 - subject `C=US,O=GeoTrust Inc.,CN=GeoTrust SSL CA - G3', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2013-11-05 21:36:50 UTC', expires `2022-05-20 21:36:50 UTC', SHA-1 fingerprint `5aeaee3f7f2a9449cebafeec68fdd184f20124a7'

- Status: The certificate is trusted. 

- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)

- Session ID: 92:C8:94:E2:E6:0D:09:C6:7B:90:00:24:4F:55:B0:4D:4A:B9:94:C1:60:DA:70:E6:98:2C:D0:AC:1E:E5:00:5F

- Ephemeral EC Diffie-Hellman parameters

 - Using curve: SECP256R1

 - Curve size: 256 bits

- Version: TLS1.2

- Key Exchange: ECDHE-RSA

- Server Signature: RSA-SHA256

- Cipher: AES-256-GCM

- MAC: AEAD

- Compression: NULL

- Options: safe renegotiation,

- Handshake was completed

 

- Simple Client Mode:

 

 

 

vrs a error

 

 

 

- Status: The certificate is NOT trusted. The name in the certificate does not match the expected. 

*** PKI verification of server certificate failed...

*** Fatal error: Error in the certificate.

*** Handshake has failed

GnuTLS error: Error in the certificate.

 

 

This will eliminate any funky thing with a browser and it's trust or policy, cache,etc.......

 

 

Use something like  ( gnu-tbs )  and follow the evidence, if you want to eliminate the FGT, set a fwpolicy b4 and to the site(s) in question and before and SSL intercept  fwpolicy

 

Don't make assumptions, don't  assume ,and follow the evidence.

 

;)

 

ken

 

 

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Bromont_FTNT

Yeah.... this isn't HSTS... HSTS only tells the browser that the page must be loaded via HTTPS and that it must be a valid certificate (correct CN, not expired etc)

 

emnoc
Esteemed Contributor III

 

http://classically.me/blogs/how-clear-hsts-settings-major-browsers   This is a browser issue not a FortiGate issue btw....

 

 

Your 100% wrong here ;)

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
CÃ_sar_Romero

Disabling HSTS in the browsers is a major security issue, and it won't resolve the issue.

 

Great aport Emnoc, thanks for sharing.

MikePruett

I may very well be wrong but I am 100% certain I have had this issue when implementing SSL inspection before and it was due to HSTS...the browser had the correct facebook cert and the cert the fortigate was using didnt match so it threw the same exact errors.

Mike Pruett Fortinet GURU | Fortinet Training Videos
MikePruett

Have you added the cert the FortiGate is using to the trusted cert directory of windows?

Mike Pruett Fortinet GURU | Fortinet Training Videos
emnoc
Esteemed Contributor III

I may very well be wrong but I am 100% certain I have had this issue when implementing SSL inspection before and it was due to HSTS...the browser had the correct facebook cert and the cert the fortigate was using didnt match so it threw the same exact errors.

 

You might have had a Strict Transport Security issue,   but  HSTS  is a layer7 function, &  SSL starts way before layer7 .  Your mixing apples and potatoes ( we not even talking  fruits here )  

 

 

For the OP confirm what was asked earlier on the trust-certificate being presented to the client?

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
MikePruett
Valued Contributor

FML....it's been a long day lol

Mike Pruett Fortinet GURU | Fortinet Training Videos
Jack_T
New Contributor

Hi all,

many thanks for help!

 

I tried to empty hsts cache on Chrome and Firefox but it didn't work

 

emnoc wrote:

I  highly  doubt HSTS is the issue. What you could do is run a non browser http  tool like  curl or ab and see what happens....

 

Use something like  ( gnu-tbs )  and follow the evidence, if you want to eliminate the FGT, set a fwpolicy b4 and to the site(s) in question and before and SSL intercept  fwpolicy   Don't make assumptions, don't  assume ,and follow the evidence.   ;)   ken

 

Emnoc, many thanks for sharing

 

I have used curl (curl.exe https://www.giustizia.it) and I received this error message: curl: (35) Unknown SSL protocol error in connection to www.giustizia.it:443

 

About guntls, is there a version for windows?

 

Thanks,

Jack

emnoc
Esteemed Contributor III

Don't know about  window but do some  google search. On curl and SSL inspection, run  curl in  verbose mode and see what certs are shown

 

 

 

e.g

 

Macintosh:~ kfelix$ curl -v -k [link]https://www.giustizia.it:443[/link]

* Rebuilt URL to: [link]https://www.giustizia.it:443/[/link]

*   Trying 193.109.206.10...

* Connected to www.giustizia.it (193.109.206.10) port 443 (#0)

* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

* Server certificate: *.giustizia.it

* Server certificate: GeoTrust SSL CA - G3

* Server certificate: GeoTrust Global CA

> GET / HTTP/1.1

> Host: www.giustizia.it

> User-Agent: curl/7.43.0

> Accept: */*

< HTTP/1.1 301 Moved Permanently

< Server: nginx

< Date: Sun, 18 Sep 2016 03:40:42 GMT

< Content-Type: text/html

< Transfer-Encoding: chunked

< Connection: keep-alive

< Keep-Alive: timeout=20

< Location: [link]https://www.giustizia.it/giustizia[/link]

< X-Frame-Options: SAMEORIGIN

< X-Content-Type-Options: nosniff

< X-XSS-Protection: 1; mode=block

< X-Frame-Options: DENY

< Strict-Transport-Security: max-age=31536000; includeSubDomains

<html>

<head><title>301 Moved Permanently</title></head>

<body bgcolor="white">

<center><h1>301 Moved Permanently</h1></center>

<hr><center>nginx</center>

</body>

</html>

* Connection #0 to host www.giustizia.it left intact

 

Guntls provide more details and the certificate in the  chain.  if your inspecting MiTM, the ssl-proxy cert should be present and trusted.

 

 

PCNSE 

NSE 

StrongSwan  

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