-1

It started a few weeks ago. One of sites gives me a message

NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

You attempted to reach some_web_site.org, but the server presented a certificate signed using a weak signature algorithm (such as SHA-1). This means that the security credentials the server presented could have been forged, and the server may not be the server you expected (you may be communicating with an attacker).

And when I click proceed I get:

Reason : The SSL server certificate authority is not trusted.

It's one of the state public service sites.

From my firewall I downloaded SSL proxy default authority certificate as p12 file and installed it in Windows in my trusted root CA. This certificate is valid until May 2022.

However, nothing changes. Is it my fault or the server owner?

Update: The site loads just fine outside of my organisation's LAN. I can load it via my mobile phone 4G network. My firewall does web filtering and SSL inspection. Does it mean that my proxy certificate is invalid? Why did it work a few weeks before and I didn't change anything from my side?

Update2 Screenshots added enter image description here

7
  • Its a problem the server owner must fix. They may not even be aware of the problem though. Especially government services sites usually have to hear it from their clients first that there is a problem before they attempt to fix it, then after they hear it, it will take some time before things get fixed.
    – LPChip
    Commented Nov 14, 2018 at 10:54
  • One way to be absolutely sure its not on your end: try with different browsers and try with different devices (pc, laptop, smartphone, etc)
    – LPChip
    Commented Nov 14, 2018 at 10:56
  • From my LAN, over my firewall it doesn't work with different devices. It works from outside of my LAN, if I go with my phone with my mobile internet provider connection.
    – Hrvoje T
    Commented Nov 14, 2018 at 11:01
  • What if you use your phone using your Wifi? Does it then work? Mobile browsers are different than pc browsers and possibly are less secure. In order to make sure you experience the same, test using the Chrome app on your phone and Chome desktop version on your pc. I estimate that both will fail the site regardless on what network you are.
    – LPChip
    Commented Nov 14, 2018 at 11:28
  • Using my WiFi over phone also fails to load a site. It's Android 8 with lastest Chrome.
    – Hrvoje T
    Commented Nov 14, 2018 at 11:31

2 Answers 2

3

You seem to be correct in your suspicions: according to the error message, your proxy certificate uses a SHA-1 signature algorithm, which has a serious known weakness. The validity time is not the issue; the bad algorithm is.

The process to deprecate the SHA-1 algorithm started years ago: with Chrome it started in 2014, as it started to flag end-entity certificates that were using SHA-1 and were valid past January 1, 2017 as "secure, but with minor errors". As time passed and new ways to exploit the weakness were discovered, the flagging was extended in steps to all SHA-1 non-root certificates and made more strict: by now, any up-to-date web browser will mark a site with a SHA-1 certificate anywhere in its certificate chain as unequivocally bad.

Certification authorities compliant with CAB/F baseline requirements stopped issuing any new SHA-1 certificates at the start of year 2016.

Microsoft also went through the process to deprecate SHA-1 certificates in 2017.

If your firewall/proxy still uses a certificate with a SHA-1 signing algorithm, it looks like you've been sort of asleep at the wheel for a while. It became apparent only now probably because of some recent security patch that finally made the SHA-1 algorithm as categorically distrusted everywhere.

You should make sure your proxy can use certificates with better algorithms (if it is up to date and can handle modern TLS on websites, it probably already can), and create a new SSL proxy default authority certificate that uses SHA256 instead of SHA-1. You'll need to distribute it to all the clients whose SSL/TLS traffic you wish to monitor. Once distributed, you can switch your proxy to use the new certificate.

With the screenshots added, it look like the browser actually is mostly happy with the certificate it is getting, as there is a good padlock icon in the address bar. The actual error message is shown instead of the page content, which makes me think this is the proxy's way of telling about a certificate validation failure on the connection between the proxy and the target site.

In the first screenshot, you're browsing outside the LAN and the actual certificate of the site can be seen. Note that it's been renewed recently, as its validity time started on 15.10.2018. The CA certificate used to certify the site is "Thawte RSA CA 2018", so even the CA certificate is at most one year old.

You might actually have a combination of two problems:

  • the browser was unhappy about the proxy's certificate with the deprecated SHA-1 algorithm, but for the time being, it still considers that a forgivable thing.
  • and the proxy was unhappy because it does not have either the "Thawte RSA CA 2018" intermediate certificate or its parent, the "DigiCert Global Root CA" certificate in its own store of trusted CA certificates, and so it cannot verify the site's recently-updated actual certificate.

At the time of this writing, the relevant Thawte CA & intermediate certificates seem to be available here.

8
  • Can I create it or I have to buy it or should I call Stormshield to get one?
    – Hrvoje T
    Commented Nov 14, 2018 at 15:24
  • And how is some sites with https working fine and some not? My ssl filter should inspect all ssl traffic?
    – Hrvoje T
    Commented Nov 14, 2018 at 15:31
  • If you're uncertain, you should probably consult the documentation of your proxy. But since a SSL proxy certificate allows what is effectively a man-in-the-middle attack on SSL/TLS encrypted traffic, it would make sense for you to handle your own certificate. That way only you (and not the firewall company too) will have the ability to monitor traffic on your client systems.
    – telcoM
    Commented Nov 14, 2018 at 15:32
  • There are newer techniques like HPKP, CT and DANE which can be used to give the browser more information about the certificate expected on a particular site. Your proxy might not be able to circumvent all these methods. That would cause the sites that have started to use one of these methods to fail while other sites that aren't using those techniques yet will still work.
    – telcoM
    Commented Nov 14, 2018 at 15:45
  • If the problem turns out to be caused by HPKP or CT combined to a browser feature that "remembers" the certificates previously seen on HTTPS sites, you might have problems with users that need to use their browsers both inside and outside the company network. (I misremembered: DANE is more of an email thing.)
    – telcoM
    Commented Nov 14, 2018 at 15:54
0

The problem cannot be fixed, except by the owner of the site getting a proper SSL certificate.

It can be worked around, for example in Chrome by adding to the shortcut the parameter of --ignore-certificate-errors.

However, with the current clamp-down on security, such workarounds have a short life-time.

10
  • I started Chrome with chrome --ignore-certificate-errors, but the site is still blocked.
    – Hrvoje T
    Commented Nov 14, 2018 at 11:12
  • Sorry, Chrome is changing the rules continuously and apparently doesn't accept overriding this particular error. Try maybe this answer for Firefox.
    – harrymc
    Commented Nov 14, 2018 at 11:16
  • Can't load this certificate in Authorities firefox certificates because it's personal certificate firefoy says. Then I tried to import it in 'people' certs and nothing happens. Still fails to load a site
    – Hrvoje T
    Commented Nov 14, 2018 at 11:34
  • If the comment exchange is correct, it is a problem on the internet connection because if I understood OP correctly, it does not happen on Chrome on the phone if they turn off WiFi and use their mobile connection instead.
    – LPChip
    Commented Nov 14, 2018 at 11:44
  • @LPChip: The difference might be in the browser on the phone. He also says it works outside of his organization's LAN, so it might also be the corporate firewall that refuses it. Hrvoje: If we had a screenshot of the browser page with the error we might know more.
    – harrymc
    Commented Nov 14, 2018 at 13:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .