The most notable changes in Chrome 54 are expanded information in the Security <\/em>panel in Developer Tools, along with fixes for two problematic bugs in macOS Sierra.<\/p>\n Lots of useful information about a site\u2019s SSL configuration lives in the Security <\/em>panel in Chrome\u2019s Developer Tools. This is where you must now go for any serious information after Chrome removed the Connection <\/em>panel (which was accessible by clicking the lock icon in the address bar) a few versions ago.<\/p>\n With the release of Chrome 54, the Security panel now provides additional information about bad SSL configurations, giving server admins a helping hand to improve their site\u2019s SSL security.<\/p>\n The Security panel will specifically call out weak ciphers and blocked mixed content in grey info bullets<\/em>, as seen in the screenshot below.<\/p>\n Another small, but helpful improvement has been made to the full-page interstitial errors that appear for major problems with a site\u2019s SSL configuration (expired certificate, obsolete protocol, etc). A \u201cLearn More\u201d link to a support page about how to \u201cFix connection errors<\/a>\u201d has been added to these Interstitial error pages<\/a> to provide a bit more context to people who encounter them.<\/p>\n Google Chrome has a functionality known as AIA fetching<\/a> to retrieve the needed intermediate certificates when a server has not been properly configured to provide them. This allows Chrome to successfully make an HTTPS connection to a site and avoids a \u201cYour connection is not private\u201d interstitial error.<\/p>\n Changes to OS functions in macOS X Sierra broke this functionality, causing a four-fold increase<\/a> in errors related to missing\/incorrect certificate chains.<\/p>\n Chrome 54 for Mac ships with a fix for this bug<\/a> that restores AIA fetching. Chrome\u2019s team refers to this as a \u201chack\u201d because it will introduce some performance penalties and they are still looking for a proper solution.<\/p>\n Certificate Transparency allows Certificate Authorities (CAs) to publically log certificates, providing proof of their issuance and allowing third-parties to audit their activity. In just a few short years Certificate Transparency has become one of the most important tools for strengthening the CA model and closing the gap on CA malfeasance.<\/p>\n As a technical mechanism, Certificate Transparency is quite complex. It is important to have a variety of \u201clogs\u201d where certificates can be publicly recorded in order to insure the accuracy, reliability, and diversity of the system.<\/p>\n In Chrome 54 two new logs have been approved<\/a>, and are now accepted as valid sources for CT information. These logs are operated by WoSign<\/a> and StartCom<\/a>, and both are public logs that will provide free logging of any certificates issued from roots in Mozilla\u2019s CA Program. These two join a short list of internationally hosted logs.<\/p>\n These logs are also now indexed by crt.sh<\/a>, a Certificate Transparency search engine operated by Comodo.<\/p>\n CECPQ1 is Google\u2019s first attempt at designing a cipher suite<\/a> that is resistant to quantum computing. Google originally launched this cipher a few months ago in Canary, and has now enabled it in a select number of clients in the stable release of Chrome 54<\/a>.<\/p>\n This is primarily a research experiment that is collecting real world data for future cipher designs. Unless you are looking out for it, you will likely never notice its existence.<\/p>\nImproved Messaging In Developer Tools<\/h2>\n
![\"Chrome](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2016\/10\/Chrome54.png\")
<\/p>\nCertificate Chain Fetching Bug Fixed In Sierra<\/h2>\n
New Certificate Transparency Logs<\/h2>\n
Post-Quantum Cipher Support<\/h2>\n