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<\/a>. \u00a0It is extremely unlikely that this will pass \u2013 so far 21\u00a0out of 25\u00a0votes cast oppose the ballot.<\/p>\n That\u00a0means, for now, nothing will change. Certificates will continue to be issued for up to 39 months. But Google\u2019s Ryan Sleevi has directly said that if the CAB Forum does not agree to a shorter maximum validity, that Google\u2019s own Root Program will, which will make it a de facto requirement.<\/p>\n [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.”<\/strong>[\/su_pullquote]<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/a>. Shorter validity periods do lead to a healthier industry and better security. Why?<\/p>\n I don\u2019t want to spend too much time talking about why<\/em> 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:<\/p>\n Let\u2019s 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?<\/p>\n 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.<\/p>\n 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.<\/p>\n So, shorter = better. Most of the Certificate Authorities recognize this, even the ones voting against this new ballot.<\/p>\n The problem is that Google\u2019s proposal is too drastic.<\/strong> 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.<\/p>\n 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.<\/p>\n So, how do we?\u00a0 First we need to get everyone on the same page and agree to a rough road map of the near future.<\/p>\n Certificate Authorities need to improve their enterprise-level tools and prepare their customers for the\u00a0big changes that are coming.<\/p>\n [su_pullquote align=”right”]“So, shorter = better. Most of the Certificate Authorities recognize this, even the ones voting against this new ballot.”<\/strong> [\/su_pullquote]<\/p>\n End-users need to know one year maximum validity is reasonable.<\/p>\n 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.<\/p>\n And browsers need to be patient.<\/p>\n When you are working on the cutting edge, like Google and Mozilla are, it\u2019s clear that this is a problem that has not been taken seriously and has persisted for far too long.<\/p>\n But the CAB Forum\u2019s 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.<\/p>\n We are talking about a world where the majority of the Alexa Top 1 Million is not yet using HTTPS<\/a>, and those that do can\u2019t set up a half-decent configuration. We are talking about a world where moving a single major site to HTTPS can take two years<\/a>. Where major ISPs<\/a> and companies<\/a> still can\u2019t keep track of all their certificates. Where certificates are being deployed on all sorts of old and unusual devices that require<\/em> painful manual replacement of certificates.<\/p>\n That isn\u2019t to say we should just accept these bad practices. But the CAB Forum and Root Programs need policies that account for these realities.<\/p>\n 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.<\/p>\n I hope, for all of our sakes, that a compromise can be found\u2014one 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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…<\/p>\n","protected":false},"author":2,"featured_media":3574,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[17],"tags":[235,583,131,192,582,179,467],"class_list":["post-3566","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-industry-lowdown","tag-cab-forum","tag-certificate-validity","tag-google","tag-mozilla","tag-ryan-sleevi","tag-ssl-certificates","tag-ssltls","post-with-tags"],"views":12132,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/02\/iStock-494443726.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/3566","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=3566"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/3566\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/3574"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=3566"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=3566"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=3566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
So what’s wrong with the proposed changes to SSL certificate validity?<\/h2>\n