New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 37 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2013
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Chrome 18 effectively blocks HTTPS on corporate network

Reported by, Mar 28 2012

Issue description

Chrome Version       : 18
OS Version: 5.1 (Windows XP)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
     IE 7/8/9: OK

What steps will reproduce the problem?
1. Go to
2. See the red "weak certificate" error
3a. Throw your computer out of the window since you can't google the problem
3b. Reinstall Chrome 17 and enjoy the internet.

What is the expected result?
HTTPS works as it should

Please provide any additional information below. Attach a screenshot if

I'm on a corporate network with a virus-checking proxy which man-in-the-middles every HTTPS connection, replacing website's certificate with its own. This way, many websites get a crossed-out "https://" in the address bar. Chrome 18 seems to have tightened the "security" by disallowing such sites to be visited, which in my case include most of google including the now-https-only search.

Reinstalling Chrome 17 helped, as described above. I've also disabled SSL false start, since it's also broken inside this network.
Labels: -Area-Undefined Area-Internals Internals-Network-SSL
We've had success so far reaching out to vendors of such MITM proxies and encouraging them to upgrade. As it stands, such solutions are unfortunately risky, and an attacker can use the weak signatures to mount a new set of attacks of the network.

Is it possible to share the vendor and version of the proxy you're using? I'll see if we can't reach out them regarding this and the false-start incompatibility.
Well, as far as I know, it's some software by TrendMicro, however, this information is of no use, since the actual certificate in question has been issued by some inhouse CA. And you can probably guess how keen the admins are to reissue that certificate.

In any case, I'd like to know: what has changed in certificate handling in Chrome 18 and how can I disable this change?
Chrome no longer accepts MD5-SHA1 certificates without user confirmation, due to the security risks involved with MD5. This was  Issue 101123  /

You can read more at or

We allow root CAs to be signed by MD5 (as their signatures do not matter to the security of the connection), but intermediate CAs and server certificates will generate errors. It's possible that either the TrendMicro software is generating certificates on the fly signed with MD5 (it wouldn't be the first one) or it's possible that the intermediate CA certificate issued to the TrendMicro software/device was signed with MD5.

Re-issuing a new intermediate cert for the TrendMicro shouldn't cause any compatibility issues if your devices are set to trust the in-house CA. If it's the TrendMicro device/software itself, knowing what version/product would be very helpful for resolving this with them.

To help you figure out, if you can attach a complete certificate chain and attach it to this bug, I can help you determine whether it's an intermediate CA or the TrendMicro device. Because such certificate chains may include information such as company name, which you may not wish disclosed, you can also e-mail it to me directly

To export the certificate chain, please see the steps here:
I might be able to help in reaching out TrendMicro: I have been in contact with one of their product manager for a different issue in the past. Let me know when you have all the pieces ready.

Comment 5 by, Mar 28 2012

I can add an additional point of information here concerning the update breaking the corporate proxy "man-in-the-middle" security suite run by my company.  My company is using WebSense.  As with the original poster, since a few Chrome versions ago, --disable-ssl-false-start has been required to use SSL in general.  With today's update to v18, this new situation is occuring and not being resolved with --disable-ssl-false-start.
wolskinj: Can you provide any further details about the specific WebSense product and/or follow the steps I mentioned in comment #3, such as attaching/sending a certificate chain?
@rsleevi: The main problem is that Chrome 18 (which normally updates itself, i.e. it's not a user's decision) can't work in certain corporate environments and there seems to be no possibility to disable the problematic behaviour. Checking the certificate chains might be a solution in long term, however, I don't really believe it, since there are many consistently broken setups where perceived control over empoyees beats security and/or correctness anytime. Apart from that, in my setup, IE8 is the mandated browser, i.e. I can't even tell them their network is broken because it doesn't work with Chrome -- their reply will be "IE8 is mandated, use that".

Comment 8 by, Mar 29 2012

I've attached a sanitized (removed company information) screen shots of the certificate information.  Unfortunately, I don't have access to any additional information around our SSL Proxy being used.
3-29-2012 9-06-43 AM.png
41.4 KB View Download
3-29-2012 8-57-26 AM.png
35.3 KB View Download
3-29-2012 9-07-29 AM.png
41.7 KB View Download
3-29-2012 8-55-38 AM.png
38.0 KB View Download

Comment 9 by, Mar 29 2012

I can echo all these problems. I used to use the -disable-ssl-false-start as a workaround. Is there a new workaround? Or am I done using Chrome at work?

You can take the "we're right" approach if you want, but that will not fix the problem for me or anyone else behind a firewall.

Comment 10 by, Mar 29 2012

See this bug for more relevant information:

#107728 references an enterprise policy. I've tried my best to apply it (I'm using MSI, I supposed it should), *enabled* the DisableSSLRecordSplitting setting, but I still get the same error. Any idea how I can verify that the setting is indeed enabled?
In my last comment, read "I supposed it should work" in the parens.
OK, I've tried playing with the policies, and now I'm sure they work e.g. changing "Application locale" worked instantly after I restarted Chrome. "DisableSSLRecordSplitting" does *NOT* work as hopen, i.e. I'm still getting the dreaded error message.
Status: Untriaged
baggus: It appears you have two different issues. Are you seeing this specific message (weak signature algorithm) when you're accessing sites?

Nikolai: The flag referenced in  Issue 107728  has nothing to do with this. Setting that flag does introduce new security risks, however, so unless you're sure you need it, you're best off not setting it.

wolskinj: Thanks for attaching the screen shots. While they don't provide all of the information needed to help you out, it does provide enough information to say that your SSL proxy is at fault. There was at least one report of a Microdasys proxy ( Issue 107845  / ), and the vendor promptly replied and indicated they'd be providing updates.

Comment 15 by, Mar 29 2012

Hi, Yes, I am seeing the red screen / weak signature algorithm as of V. 18 for every SSL site that is proxied by our Websense Proxy. My screenshots would be the same as above except with our company name as the CA.

This mainly affects sites that our company doesn't trust (facebook, google, etc.) and not banking or medical sites. That may make the problem seem intermittent to some (false bug reports).

I have no say over when or if our company will remedy the proxy issue, so I would definitely appreciate a workaround if possible. I usually use Chrome on a daily basis.

Comment 16 by, Mar 29 2012

Yes, similar to @baggus, my company does not typically update infrastructure items such as our web proxy often (except for security problems).  Additionally, since Chrome is not officially supported withing the company, our IT group will not make any specific adjustments to support.  A browser based solution is likely the only option for me for several months to a year (the next likely proxy upgrade).
Please be aware that future releases of Firefox will also include dropping support for certificates whose signature-hashes include MD5. Further, Apple has made similar moves with iOS 5, and will presumably include those changes in a future release of OS X and Safari.

The fact that the proxy is issuing these certificates does represent a form of security vulnerability - an attacker can potentially spoof such certificates and cause you to believe you're talking to a real/authorized site - and for that and reasons like it, this move has been made.

I believe we may have some contacts with WebSense that I'll see if we can reach. I believe this issue may have been brought to their attention before (as with --disable-ssl-false-start), and they had indicated they were working on it.
I'm sorry, you still don't get the problem. There are situations you can't solve with evangelism and talking. Those are exactly the situations you solve with configuration options and it doesn't even matter how deep I need to dig to flip the switch. There are people out there who can't use Chrome in their corporate environments RIGHT NOW (and no, switching to Bing search doesn't count). It doesn't matter if current setting is technically correct, it doesn't matter if it'd be insecure without it, there should be a way to disable a setting which makes basically the whole internet unusable in Chrome (yes, is HTTPS-only now and broken). 

Please be aware that neither Firefox nor Chrome nor Safari nor iOS nor any other browser or platform apart from IE(8/9/10) will be used in our environment for the next year, no matter how advanced, fast, compliant, secure or environmentally friendly it is. There is not a single chance that Firefox or Chrome or anything else will ever be the standard browser. Even if Microsoft is going to block certificates the same way with IE10: Where I work, IE10 is considered for introduction in 2014 and they also have a ton of Microsoft consultants running around who WILL fix any kind of problem IE(8/9/10) might have with the environment, including patching the browser to allow weak crypto if the customer tells them so. This is apparently something Google is not prepared to do, even though they want to push Chrome into enterprise market.

For those of us who want to use Chrome in such environments (and I use it extensively for web development since the first public version) it becomes more difficult with every version. After SSL False Start which has put into an endless redirect loop but was still disableable, we now get auto-blacklisting of weak crypto without any remedy for the affected ones, which would only need to consist of a single small switch hidden somewhere deep, but reachable inside your product ("Yes, I understand the risk, let me go anyway" button). Please don't think FOR your users, but instead ABOUT them.

Thank you.
Hi there, I am having the exact same issue with the Chrome 18 update. I am using Chrome in a corporate environment. SSL sites do not load. I believe our vendor is Websense. Please get this fixed! Everything worked fine in Chrome 17. 

Comment 20 by Deleted ...@, Mar 30 2012

Is an update coming with the ability to turn this off via group policy?  This is needed in corporate environments.
Status: ExternalDependency
WebSense has been aware of the issue since this was first introduced and is planning an update.

At this time, there are no plans to provide compatibility flags. We remain committed to evaluating the impact and scope of this change, and that may change in the future. However, because past history has shown that once compatibility flags are introduced, vendors tend encourage their adoption rather than address the underlying security concerns, leaving users at risk, there is a high bar for determining whether or not a security feature should be disabled.

This issue has been known about for quite some time, the plans for Chrome/Chromium moving away from MD5 have been publicly discussed since 2009, and the weaknesses of MD5 have been known for over a decade. The issue has been sufficiently known to vendors for some time, and preparations have been in progress for years. Users of security products that are affected by this may wish to speak to their support contacts about why such security risks are only now being addressed.

While at this time, this is looking to be a WontFix. I'm going to mark it as ExternalDependency, so that users affected by this will be able to locate it when searching.
I am also having this issue in a corporate env. We are also using TrendMicro as our Proxy.  Is this a Trend issue or in-house ca issue as it appears our in-house ca is signed using MD5?

Comment 23 by Deleted ...@, Apr 2 2012

I found a workaround...use VPN while at work.
Boshell32: Perchance do you have any additional information about the TrendMicro proxy you're using, such as name or version?

Comment 25 by, Apr 3 2012

In our corporate network environment we use a proxy server which man-in-the-middles every HTTPS connection. This is very common in corporate networks especially in finance sector.

After installing server certificates (before Chrome 18) to client machines we started to get HTTPS connection errors. After googling around I found the solution was enabling Chrome option "--use-system-ssl". With the latest Chrome update, version 18, now we can't even connect to Google services such as Gmail, Plus (Facebook is ok since we can click on "Proceed anyway").

Right now I am using IE9 to write this comment. I agree with Nikolai. Google doesn't understand the problem well for users in enterprises. Of course, it is ok to try to be the most secure, I get it. But trying to force every corporate network administrator to install patches "immediately" to fix MD5 certificate problem is too much optimisim. There are millions of corporate networks and admins and they need time. Instead of this mandatory approach, an option to allow MD5 certificates helps both us users and network admins to adopt.

I don't think this is much different from clicking on "proceed anyway". So a WontFix status means I (and millions of other users) have to use IE or another browser until all of our network admins install the hotfixes, or upgrades. Since you don't get the idea of a corporate network it is also good to point enterprises don't often install hotfixes as day gets released. There are "planned down times" which occur montly, or even longer intervals.
I'm having the same issue as well, but it seems that for those of us that have Websense as the middle man there is a solution. I can't vouch that it works yet, but if we have the patch applied, I will report back and let you know. It is in the link to websense:
At the bottom of the page. They must have just posted the hot fix as I checked the page yesterday before noon and I did not see it. 
Rsleevi: we are using Trend Micro InterScan Web Security Virtual Appliance 5.5
Seems to me like we should have a policy to disable the warning, so admins can suppress it while they work to update their proxy.

Filed for this.

Comment 29 Deleted

Comment 30 by Deleted ...@, Apr 5 2012

Please add option to bypass this warning...
Our security guru worked with Websense to apply the hotfix listed in their post and I can say all is well again with Chrome on my side. 
Can you list the hotfix or does Websense know the exact issue?  Our Websense guy is out and I'm dealing with the fallout from this.  
It is in the bottom of this link:

Our admin had to talk to Websense to get the patch installed. 

Comment 34 by Deleted ...@, Apr 9 2012

I also have the issue as stated in Comment 15,  with Websense behind a corporate Firewall.  Websense will not block IE8, but every HTTPS connection in Chrome (And FireFox as well) since the recent update.

Comment 35 Deleted

Comment 36 by Deleted ...@, Apr 9 2012

We ran into the same issue. Seriously guys, I understand the security implications of this. But WHY WOULD YOU NOT ALLOW THE USER TO DISABLE THIS CHECK? Stop trying to control everything so tightly. And it's not just with this issue either. I ran into Chrome blocking certain non-standard ports which I use for a video security system. I was at least able to enable them from the command line. But still, things like this are a major annoyance. You need to allow the user to easily disable these sorts of thing in the configuration.
Labels: nomedia

Comment 38 by Deleted ...@, Apr 10 2012

I too am having the same issue with Websense and their man-in-the-middle HTTPS handling.  Google websites such as picasa and "" come up with plain text and broken images.

Firefox 11 works as does IE 9.
This effects me also. I agree with the other commenters that there really should be a configuration option to disable this restriction. I do understand the security risks. I also understand that a hotfix is available from WebSense. What I don't understand is Google's expectation that the types of organizations that would use this type of proxy setup (eg: large organizations with many employees that can't be trusted to use the internet without supervision) would be the same types of organizations that would be willing to roll out a hotfix at a moments notice to accommodate a relatively small number of those users who are clearly up to no good by using some upstart rogue browser. Obviously this is not Chrome's target market segment so I understand the desire to protect the public at large from what would probably be a malicious intent if encountered in the wild. But within a corporate setting, the exposure from this 'weak' signature is confined to within the corporate firewall. 
At a bare minimum, at least let these users click a button that says 'Somebody is surely spying on this communication, are you sure you're ok with that?'. Blocking them entirely seems heavy-handed.

Comment 40 by Deleted ...@, Apr 10 2012

What is recommended for people who work at large corporations that will not apply hotfixes such as the one available thorugh websense?  Many people I work with have complained about the situation.  I find it odd that a google product does not allow me to check my google mail regardless of the proxy I am using.
I'm concerned at Google's apparent lack of interest and thought in this kind of issue. I've recently begun consolidating my browser usage towards just Chrome on all my various PCs, but this will now have to immediately reverse this and it'll be relegated to just "test" status on a single PC.

I work on various client sites, generally large enterprises, and cannot choose a browser that'll probably be unusable for the next 1-2 years (my estimate of the time period until I would expect - not just hope - that the majority of current & potential client sites will have updated all their various proxy servers).

Back to Firefox it is, and thence to IE9 in the unlikely event that Mozilla are stupid enough not to provide an option to disable it as and when Firefox gets a similar update. For all Chrome's good points, I suspect it'll be a long time before I look at it again for any serious use - the track record for this kind of issue makes its simply too risky (the sudden removal of side tabs being another case in point).

Effective workaround.  Download Chrome version 17.0.963.83.  It will not automatically update and it works. 
I want to strongly discourage the solution from #43. In addition to suffering from the weaker security of MD5, you will be exposing yourself to known security vulnerabilities that the automatic updates address.
Re: Comment 44 by

The alternative to for people such as myself in enterprise environments is to not use Chrome at all. I had been using Chrome as my dedicated browser, after the update to v.18 I no longer use Chrome at all. 

Comment 46 by, Apr 16 2012

jbsmith317 thanks for the tip.

Rsleevi yes Chrome 18 fixed the security problem of the entire Internet. I can't access any of the useful services. Thank you to automatic updates too.
Enterprise environment. Chrome hosed. I can't twist my corporations arms to get rid of the firewall and I can't twist your arms to treat me like an adult and allow me to downgrade my security by choice. If you are too shortsited to see the problem you're causing yourself, then I will not mourn your loss. I am uninstalling Chrome. I like extensions better than anything anyone else offers, however, I also like the internet, which you no longer offer. I don't have time to monitor this for a fix, so I'm just going back to IE full time. Good bye.

Comment 48 by, Apr 25 2012

Is there any chance this will be fixed soon?

Sent from IE9 which works in our corporate network.

Comment 49 by, Apr 30 2012 - checked that link, but can't see anything regards a hotfix.

Got any more details? Contacting Websense anyway, but if you have any mroe info, I'd appreciate it.

Comment 50 by Deleted ...@, May 2 2012

Is this still largely a global issue? I'm in a corporate environment, behind Websense, and i noticed it's been over a month since someone has posted in here. Though I'm still having this issue. Typically I use either the IE tab extension in Chrome as a workaround, or if it's really bad, I fire up the mobile hotspot on my phone and use my USB wifi adapter on my desktop. But seriously, this is a whole new level of annoying. Is my company just slow in getting Websense to address this issue, or is it still affecting most users? Any other possible workarounds out there apart from backpedaling to v17?

Comment 51 by, May 2 2012

It's still an issue for me, so I run Chrome 17 as a workaround. I think I'll be running this version for a very long time! Firefox may be v. 30 before I can run new Chrome again! :-)

Comment 52 by, May 2 2012

comment #50: Comment 21 has the fix. It sounds like your company has not yet installed the fix?
We had to manually apply, with the help of Websense, the hotfix. It wasn't something that, to my knowledge, was pushed out to anyway. Our network security admin is awesome though, so he was fast on getting everything working. He was able to setup a workaround before he actually was able to get in the fix as well. I don't know what it was, as I'm not a networking guy, but he setup the workaround in about an hour after getting my message about it. 
It is still a problem at our office as well. The solution is simple: don't use Chrome. Chrome is not an official browser here so the IT could care less about any Websense fixes etc...

Comment 55 by, May 2 2012

I AM the IT at my work :)
currently awaiting Websense to get back to me and give me the fix, and then I'll get it applied asap.
Chrome isn't supported here either (only IE is - welcome to the corporate world!) but pretty much all of IT use it.
Websense willl be releasing it publicly, but only as part of the upgrade to 7.7, which isn't due for at least 3 months or so.
Same issue as other posters - corporate network, MITM Websense ssl proxy, no chance of getting a hotfix from Websense installed on the network within the next year.
Going to have to stop using chrome, or find an older version. ++

Comment 57 by, May 4 2012

ok, just applied the fix to my backup Websense proxy (not allowed to touch the primary just now, until we fully test and get the ok to change the production system).

It works perfectly - no issues accessing HTTPS.

If anyone else is contacting Websense about it, then this is the Hotfix you want:
WCG 7.6.2 Hotfix 05 SHA-1 Support

Websense WILL want to remote connect to your system to apply this, unless you sign an NDA with them to do it yourself.

Comment 58 by, May 11 2012

As an addition, Websense have now released v7.6.5 which fixes this issue, and others as well.

just upgraded the backup appliance - no issues whatsoever,

Comment 59 by Deleted ...@, May 15 2012

Okay, so my company has a ton of internal https servers.  To date, about half of them have been updated with stronger certificates.
Unfortunately, they have a lot of more important things to do (you know, like help us make money) and they are extremely busy.  Since these are actually just internal only servers and run ssl only because that's how the product installed, they don't really rank very high on their priority.  So, here's the deal: you are socially training me to just click right on through the stupid red security warning page.  And, I just found myself clicking proceed when it wasn't even the weak certificate error since I get it all the time!  DOH!  So, good job Google, you've socially engineered that particular warning page right out of usefulness!  Security is often more about just warning and annoying people.   It would have been really great if you could have just made it so I could say, yeah, yeah, websites on this domain are okay to have weak signatures.  But no, you have to take a stance that forces IT departments everywhere to get off their butt and do some work.  Sure, this is a good thing for internet sites, but did you know there really are a heck of a lot of internal websites all around the world.

Comment 60 by Deleted ...@, Jul 3 2012

Same issue for me in a corporate environment.

Comment 61 by, Jul 3 2012

well, thats Websense version 7.7 out (which is supposed to contain a fix for this, amongst other things).

Due to the fact its a bit weighty (1.8Gb for the appliance, 2.3Gb for the Windows component) and it downloads at a maximum of 40kb/s (thanks Websense!), it may be some time before I get around to actually putting it in place.

Comment 62 by, Aug 9 2012

It's been 5 months and I still have to use version 17 in order to access Google services behind our corporate firewall. WebSense tried to upgrade last month but failed. It is ironic imho the mandatory security feature forces me to be insecure.
This bug is now almost half a year old and barely anyone from the Chrome team looked at this bug. What can we do to raise awareness and reach some kind of agreeable solution?
re #56 - issues have been resolved by a websense update. I still think that these security features should be optional (and enabled by default).

Comment 65 by Deleted ...@, Oct 4 2012

Nothing yet?  Same problems as everyone above.  Both IE and FF work - no Chrome, though.

Comment 66 by, Oct 12 2012

I have to agree that Chrome's refusal to allow us to "proceed anyways" is beyond frustrating. When did it become your job to be our nanny? We're forced to use IE or Firefox at our workplace, both of which allow us to "proceed anyways".

What makes me really laugh is the last statement on the Chrome security warning:

"You cannot proceed because the website operator has requested heightened security for this domain."

Chrome could at least be honest and say, "You cannot proceed, because we want to do your thinking for you."
ahon...: One of the key goals of Chromium and Chrome is Security. This is demonstrated through Chromium's unique multi-process architecture, the aggressive sandboxing, and the various innovative features, such as sandboxed Flash, that have been used to make the web a safer place. The lack of "proceed anyways" on *some* pages, particularly "high-value" pages, is a key part of that, and has been very important to protecting users from malware and from attacks by their own governments.

If you're not seeing a "proceed anyways" button on internal sites, then that's a bug and you should file a **new** bug with network details -

If you're seeing this bug because your proxy is using insecure algorithms, then that is working as intended - the algorithms are so insecure that your proxy is undermining browsing security, and your browser should warn and protect you.

That message is supposed to appear exactly when the site operator HAS requested hightened security, such as using public key pinning ( ). It's not Chrome being misleading.

Comment 68 by Deleted ...@, Nov 13 2012

I would like to add to the comlaints here - sadly there is nothing users like ourselves can do to influence corperate network admins.

We are not children. If we know the risk, we should be able to take it.

HTTPS is not just used by banks, or payment portals these days, it is used for google search, twitter, google+, etc. Chrome is useless to a LOT of people.

I am writing this in IE and it looks like I have no other option than to get used to it.
Status: WontFix
Marking this as WontFix. The MD5 decision is one that will not be re-visited for Enterprise, as it is totally broken. Most (all?) affected vendors have released security updates for their enterprise MITM devices and software, and users should install these.

Comment 70 by, Jan 22 2013

This is a disappointing turn of events for Google Chrome and showing a very basic misunderstanding of the pace of update and conservative approach to such major changes in infrastructure in large companies.  A change of like this requires at least six months of regression testing and piloting prior to beginning of roll out (that's assuming the company even owns the license to the most recent version that has a patch available).  Back to IE8, the only officially supported browser in my company.
Project Member

Comment 71 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network-SSL Cr-Internals Cr-Internals-Network-SSL

Comment 72 by Deleted ...@, Dec 29 2014

Or it could be a misunderstanding in reverse...if your company doesn't update browsers frequently, requires 6 months of testing before doing so, why are you updating Chrome frequently?  If everyone in this thread turned off the "auto-update" in Chrome, and updated it according to how their company (slowly or doesn't) updated everything else, they would not have had any issues.  It is foolish to expect that Google doesn't update or fix known security issues in the latest releases of their product.  If you need special cases, then operate within them, but don't expect Google to do it.  You might have Microsoft consultants running around willing to do whatever, but that is only because your company is paying Microsoft a ridiculous amount of money to do it.  I doubt they are paying that same amount to Google.  Even 2 years later.  This is really no different than Microsoft dropping support for XP.  Those who wish to still use it and get support have special agreements worked out with Microsoft.  In general, it's not up to a company to help you be less secure.  Any company should avoid that at all costs, simply because of liability claims.  You want to be less secure?  Keep using the older versions of the browser then, but there shouldn't be a disable option for this one.

Sign in to add a comment