I am hearing that the SHA1 Deprecation notices from MS/CHROME only apply to certs that are a part of a public trusted root program. This makes one believe that IE will have new logic built in to allow it to distinguish certs issued by internal CA's as opposed to certs issued by Public CA's and NOT flag sites as unsafe that are deemed to be SHA1 internal?

So the way I see it is its kind of pointless to leave SHA1 legacy copies of certs in the trusted root store as a fallback if the browser is going to flag all SHA1 certs as unsafe anyway. Unless you are simply going for connectivity for legacy platforms that can't use SHA2 and don't care about warnings.


3 Answers 3


Microsoft has had the logic in place for some time.

By default, any certificate that is a subordinate of a trust anchor from the Microsoft Trusted Root Program will not be trusted after the cut-off date if the subordinate has a SHA1 signature. Any SHA1 certificate that is a subordinate of a locally installed trust anchor will still be trusted. This is the case for all applications that use Microsoft's built in CAPI for their certificate processing, which includes Internet Explorer and later versions of Chrome.

Mozilla decided to do their own thing with the Firefox browser (as it doesn't use CAPI) and stopped trusting any SHA1 certificates, regardless of whether the trust anchor is internal or part of the Mozilla Trusted Root Program.

Remember that all trust anchors are trusted because you (or the browser/OS developers) explicitly placed them in the trust anchor store and not because they are digitally signed. Therefore, whether the trust anchor certificate has a SHA512, SHA1 or MD4 signature makes no difference whatsoever - the signature is not used to imply any trust or security in the certificate.


I don´t think there will be a restriction on certificate path validation when they talk about this but a restriction on CAs accepted on the Public Trusted Root program. Those that use CA will not be accepted anymore. Therefore, they will be removed from the default installed ones in the system. You still would be able to add any CA you want on the trusted list (including those that get to be removed from the public trusted root program) and all will be validated and trusted equally.

When they really deprecate SHA1 by avoiding SHA1 based path validation, it will probably affect all CAs equally, internal or not.


I'm fairly certain SHA-1 will be deprecated by most OS's by 2017. Especially with browsers taking the initiative and flagging certificates secured by SHA-1 by mid 2016 and Google's project Zero cracking the whip on implementing encryption over the web.

The issue here isn't about connectivity. It's about pressuring network administrators/device manufacturers/software developers to implement their encryption intelligently. Honestly, your even if your CA is an internal one SHA-1 has been proven to be breakable.

In my opinion, why implement encryption at all if you're going to do it wrong?

  • 3
    That's rather draconian and narrow-minded. Often companies have good reasons to delay upgrading a legacy system since this can be very expensive / disruptive. Our job on this forum is to provide information, not to judge their business decisions. For example, wrapping all interaction with the internal CA inside a modern VPN could be an acceptable and cheaper alternative to upgrading the CA and pushing new client certs to all devices. Commented Dec 2, 2015 at 16:02
  • Browsers could add exceptions to accept SHA1 for internal domains. If it is an internally facing system, the risk of staying with SHA1 would be minimal.
    – Stone True
    Commented Dec 2, 2015 at 16:12

You must log in to answer this question.

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