Articles tagged as “Chrome”
Articles I've written
Since 2020, maximum lifetime of HTTPS certificates is limited to 1 year, exactly 398 days. I've previously written about the history and the reasons behind the change. But the reduced lifetime applies only to certificates issued from a public certification authority (CA) added to the operating system's or the browser's trusted root store by the vendor.
Starting with Chrome 113, you can override HTTP response headers, or add a new one. This is handy as you can override e.g. some security headers for testing. The HTTP response header override will be applied before things like CSP are processed so you can modify the Content Security Policy for the page for example.
In February 2020 at the CA/Browser Forum in Bratislava, Slovakia (and later officially), Apple has announced that starting September 1st, 2020, maximum TLS certificate lifetime in Safari (and probably in the whole macOS and iOS and all apps) will be just 1 year, 398 days exactly. Apple's change has been followed by both Chrome and Mozilla later that year. That's very good news. But why?
Microsoft, Google, Apple & Mozilla announced yesterday that they're removing TLS 1.0 and TLS 1.1 protocols from Internet Explorer, Edge, Chrome, Safari & Firefox browsers in the beginning middle of 2020. Your visitors most probably don't use them already so you can disable them in your server configs today. But let's verify that first using the “Handshake Simulation” tool available in the SSL Labs Server Test.
Magical properties are often attributed to the padlock icon 🔒 which marks “secure” pages. For example, you'll often hear that the icon indicates trustworthy websites that won't abuse your data and passwords. The padlock is gradually being removed and that's a Good Thing™. But why?
Chrome started marking all HTTP websites as Not secure yesterday (on my birthday, what a gift!) with their release of Chrome 68. The treatment is not a red warning yet, just a gray (i). And there's a lot of busy czech websites getting that treatment. And how did we get here anyway and what's next?
ERR_SPDY_PROTOCOL_ERROR, and an invalid HTTP header When migrating your site to a more performant HTTP/2 protocol, it may happen that Chrome will not load a page and will display This site can’t be reached with ERR_SPDY_PROTOCOL_ERROR instead. HTTP/2 is derived from the earlier SPDY protocol, that's probably why the error message doesn't mention HTTP/2 at all. I'll show you how to figure it out with chrome://net-export.