You are here

You are here

Google, Apple, Mozilla enforce 1-year max certificate expiration

public://webform/writeforus/profile-pictures/richi-2016-480.jpg
Richi Jennings Industry analyst and editor, RJAssociates
 

If you use TLS certificates with long validity periods, then listen up. Any cert issued after next month needs to last no longer than a year (plus a month’s grace). 

That’s right: 398 days is the maximum length for a publicly issued server cert. If it’s longer, browsers and other HTTPS code will reject the cert as invalid.

Wait, when was that agreed? Um, funny thing: It wasn’t. Apple did it unilaterally—despite the proposal being voted down in CA/B. And then Google and Mozilla followed suit.

Outrageous! In this week’s Security Blogwatch, we play both sides.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Reality.

Time’s up for lazy DevOps

What’s the craic? Shaun Nichols reports—From Sept 1, new TLS certificates valid for more than 398 days will be snubbed:

For developers and site admins, that means if you're creating or renewing certs after September 1, make sure they expire within … 398 days … or they won't work as you expect in Safari, on iOS, and with other Apple software. Users may see error messages or notice connections fail and services break.

Critics, particularly commercial certificate sellers, say it burdens software makers and site owners with extra costs and hassle, and will drive folks to free services, such as Let's Encrypt – which, incidentally, offers tools to regularly and automatically renew certificates at no cost. … Suffice to say, certificate sellers were irritated by the change.

Google's Chrome is set to follow suit, judging by this commit to the Chromium … code last week: “Enforce publicly trusted TLS server certificates have a lifetime of 398 days or less, if they are issued on or after 2020-09-01. Certificates that violate this will be rejected with ERR_CERT_VALIDITY_TOO_LONG and will be treated as misissued.” And Mozilla is preparing to adopt the policy in its Firefox browser. … All eyes are on Microsoft, which is expected to make a decision … by the Fall.

Spokespeople for Mozilla and Google were not available for further comment.

And Ben Lovejoy adds—After Safari boosts HTTPS protections, other browsers follow:

Back in February, Apple announced plans to boost HTTPS protections in Safari, with effect from September 1. … Apple will only accept … certificates as valid if they were issued within the past 13 months.

[But] not everyone is happy about it. Traditionally, the validity period of certificates is decided by a body known as the CA/B Forum, comprising a mix of Certificate Authorities (CAs) – the companies which issue the certificates – and browser makers. CAs [argue] that shorter validity creates more work for IT companies.

In a vote last year, the CAs won and the browser makers lost. However, Apple decided to act unilaterally.

That doesn’t sound fair. Casey Crane is even-handed—Google Chrome to Join Apple’s Safari in One Year Certificate Validity:

One year validity for SSL/TLS certificates has been a hot topic of conversation within the CA/B Forum for years. … Although their past efforts to push one year validity had previously failed, Google is ultimately getting what they want after Apple announced in February that they were leading the charge on this one.

That made for a nice early birthday present for Google. But hey, it’s all for the greater good of security, right?

[But] going from two year certificate validity to one year means that your certificate lifecycle is, essentially, cut in half. This means that there will be double the chance to miss an expiration [and] more busywork in terms of certificate management.

[So] now’s a great time to implement certificate automation. … While I don’t foresee the browsers moving toward a push for 9-, 6- or 3- month validity very soon, I wouldn’t be surprised if we see things eventually move in that direction in the future.

Should we care? Paul Ducklin asks exactly that—Should we care?

It was essentially implemented by Apple unilaterally early this year, apparently without industry consensus, and is now being copied by Google. … In other words, it feels to some people like a sort of “policy by stealth,” given that with both Apple and Google now behind it, the opinion of everyone else doesn’t matter because everyone else will need to follow suit.

Others ask why a year is seen as “too long” given that certificate authorities such as Let’s Encrypt are already issuing certificates that are only valid for three months at a time, thanks to a smoothly automated process for renewal. [So] how can one year be considered too short for certificates from more mainstream, traditional certificate authorities?

You can fight it – or you can go with the flow and adapt your certificate renewal workflow to acquire and use one-year certificates. … The good news … is you end up with a definitive list of servers that are supposed to be there, rather than buying long-life certificates and forgetting them.

Is this a great time for everyone to migrate to Let’s Encrypt? NikNakk knows:

Great though Let’s Encrypt is, it does not offer Organization Validated … certificates. Commercial organisations that want to have those … will need to keep buying commercial certificates.

For the rest of us, Let’s Encrypt seems to work really well and makes configuring HTTPS on supported web servers pretty painless.

Wait, how safe is that? He’s im_thatoneguy:

Certs don't tell us anything about the safety of the website. The only thing Certs do is ensure the connection is secure to the website you're visiting.

People have criticized Let's Encrypt for offering https certs to phishing sites but those critics completely ignore the fact that https certs never have meant the site is safe, just that you connected to the address in the address bar.

But greatgib is spitting feathers:

Remember the good old time when it was not an almighty cartel of browsers that controlled your internet? [Now] a limited number of people use their corporate interests to decide for the whole world with almost no discussion.

The worst is that the "security" argument for this change is quite weak. … You as a user are so stupid, that browsers will decide for you what website is deemed safe for you to visit.

What a pain in the ***. Tysonmoth neatly lays the blame:

I blame the CAs. [They] have been extraordinarily sloppy with their responsibilities over the past decade, dealing out certs without validation and losing the security of their most important private assets. … The CAs have improved their business processes, but it’s been slow.

Trusting the CAs of two years ago is not a good idea. Therefore, the browsers [now] only trust the CAs from the past 13 months.

Conversely, Maelstorm points elsewhere:

So when did Apple start to dictate to the end user about website certifications and how long they are supposed to be? The length of time should be a matter of administration, not being shoved down people's throats.

I do not purchase Apple products. [Yet we] have to deal with the fallout of their decisions.

Meanwhile, Guspaz sounds slightly sarcastic:

I'm sure the CAs aren’t thrilled that they get to sell … certificates more often than before. Oh no, Apple is forcing us to make more money, woe is us!

The moral of the story?

Automate, automate, automate. And brace yourself for the next contraction of cert validity.

And finally

Kirby is back on his old remix schtick

Previously in “And finally”

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

This week’s imgsauce: Manfred Richter (via Pixabay)

Keep learning