(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

February 22, 2017 3

Finding Reasonable Changes To SSL Certificate Validity

in Industry Lowdown

A balance needs to be found between security and usability.

This week the Certificate Authority and Browser Forum (CAB Forum) is voting on a ballot that would make changes to SSL certificate validity by reducing the lifespan to a maximum of 13 months.  It is extremely unlikely that this will pass – so far 21 out of 25 votes cast oppose the ballot.

That means, for now, nothing will change. Certificates will continue to be issued for up to 39 months. But Google’s Ryan Sleevi has directly said that if the CAB Forum does not agree to a shorter maximum validity, that Google’s own Root Program will, which will make it a de facto requirement.

[su_pullquote]“We need a balanced policy that can get us a meaningful reduction in maximum validity without making fully-manual certificate replacement a nightmare.”[/su_pullquote]

This is a major moment for the industry and for the CAB Forum. If Certificate Authorities (CAs) and browsers cannot reach a compromise, changes will be forced onto an industry and customer base who are unprepared.

The main objection from CAs is that their customers are not yet ready for yearly certificate replacement. If you have only ever managed a single certificate, this may seem like a strange argument. But there are scores of enterprises deploying certificates upwards of ten thousand certificates at a time, with red tape and difficult policies that slow down the entire process, and outdated and unusual systems that have lackluster support for SSL/TLS.

But Google (and Mozilla) think that long-life certificates have existed for too long and want to make a change now. And they have a pretty good argument on their side. Shorter validity periods do lead to a healthier industry and better security. Why?

• Faster and more regular certificate expiration means new policies and cryptography can be adopted quicker. This is incredibly valuable to the ecosystem. It also gives the assurance that all SSL certificates are no worse than X months ago’s practices – the smaller that X is the more value that statement has.
• The possible damage of mis-issuance is reduced. This is especially important given that revocation methods are not totally reliable and some clients may accept a certificate until it expires.
• It encourages organizations to take a more proactive stance on certificate management and update their configurations more frequently. When certificate validity is too long, server admins forget where they have certificates deployed, which leads to expired certificates, neglected configurations, and a dismissive attitude towards the importance of SSL.

I don’t want to spend too much time talking about why shorter validity is good, but even for those familiar with SSL it can be hard to put into context. So here is a quick example:

Let’s say the industry decides that certain validation procedures are not reliable enough (which is something that did recently happen). They discuss the changes needed, someone proposes a ballot, and it is passed. Great! Procedures have been improved so the ecosystem has been improved, right?

Wrong. Certificates that used the old procedures will continue to exist for another 39 months. Long after many remember that a change happened, old non-compliant certificates will still be out there. Users are hurt because they have to wait years to see a real internet-wide improvement.

Software vendors (like web browsers) that validate certificates and enforce compliance are also hurt, because they need to adopt all sorts of complicated logic to account for the long phase-out period. This is a real problem that browsers constantly face which requires rolling back changes, creating exceptions, and all sorts of other messy compromises.

So, shorter = better. Most of the Certificate Authorities recognize this, even the ones voting against this new ballot.

So what’s wrong with the proposed changes to SSL certificate validity?

The problem is that Google’s proposal is too drastic. Right now we have a maximum validity of 39 months for DV/OV SSL, and 27 months for EV SSL. Google wants to jump multiple steps at once, reducing all certificates to a single year of validity and enacting the change in just 6 months.

It is overwhelmingly clear that without pressure, there will never be change and we will never get to a place where yearly certificate rotation is possible. We need to get there.

So, how do we?  First we need to get everyone on the same page and agree to a rough road map of the near future.

Certificate Authorities need to improve their enterprise-level tools and prepare their customers for the big changes that are coming.

[su_pullquote align=”right”]“So, shorter = better. Most of the Certificate Authorities recognize this, even the ones voting against this new ballot.” [/su_pullquote]

End-users need to know one year maximum validity is reasonable.

Organizations and server admins need to start looking at new technologies and policies which will allow them to replace certificates quicker. This means making real changes and investments that will allow them to easily replace their certificates, whether they are working with a handful or 20,000.

And browsers need to be patient.

When you are working on the cutting edge, like Google and Mozilla are, it’s clear that this is a problem that has not been taken seriously and has persisted for far too long.

But the CAB Forum’s policies have the difficult task of keeping the internet safe while also accounting for the sluggish enterprise sector and all the strange (and ultimately unwise) use of publicly-trusted SSL on non-public networks.

We are talking about a world where the majority of the Alexa Top 1 Million is not yet using HTTPS, and those that do can’t set up a half-decent configuration. We are talking about a world where moving a single major site to HTTPS can take two years. Where major ISPs and companies still can’t keep track of all their certificates. Where certificates are being deployed on all sorts of old and unusual devices that require painful manual replacement of certificates.

That isn’t to say we should just accept these bad practices. But the CAB Forum and Root Programs need policies that account for these realities.

That means for now, we need a balanced policy that can get us a meaningful reduction in maximum validity without making fully-manual certificate replacement a nightmare. For example, a maximum validity of 27 months effective early Q4 this year strikes that balance.

I hope, for all of our sakes, that a compromise can be found—one that inspires urgency and a real effort to improve certificate practices, without making too many server admins miserable due to forces that are mostly out of their control.

• #CA/B Forum
• #Certificate Validity
• #Google
• #Mozilla
• #ryan sleevi
• #SSL Certificates
• #SSL/TLS