Last month we discussed the new regulation from the CA/Browser Forum that SSL/TLS Certificate validity periods will be capped at two years, instead of three, starting March 1, 2018. Typically, after we make a CA/Browser Forum related announcement, we get a lot of questions – who are they to take away my precious three year certificates? Who is this mysterious “almighty power” behind all of these changes?

At a high level, the CA/Browser Forum is an industry body made up of Certificate Authorities (CAs) and web browsers with the goal of advancing “industry best practices to improve the ways that certificates are used to the benefit of internet users and the security of their communications.” 

So, now you know who they are. To learn more about how they operate and why they make the changes they do, we went right to the source - Doug Beattie, VP of Product Management at GlobalSign, and active member of the CA/Browser Forum for the past three years.

Hi, Doug!

CAs and Browsers Make up the Majority of the CA/Browser Forum. What Role Does Each Party Play in Information Security on the Web?

Certificate Authorities (CAs)

CAs are responsible for following the industry requirements and standards when issuing certificates. One of the main areas is validating the certificate information and filtering out requests that look like phishing sites. This process is known as vetting.

It’s important to be careful who we issue certificates to and that we make sure to follow security best practices for a safer and secure web. There are set out in Baseline Requirements that state that all CAs must implement high-risk checks to make sure they review certificate requests when they look suspicious. This is why we (GlobalSign) have a phishing filter, which is regularly updated based on new information. This is also a reason behind the upcoming CAA (Certificate Authority Authorization) requirement, which allows domain owners to specify which CAs can issue certificates to the domain/s (note: more on CAA further in the post).

We all play a part in internet security, so CAs should be careful about saying ‘internet safety is not our problem; we just issue certificates’. We aren’t responsible for chasing down hackers and arresting them, but we certainly have a part to play and should be doing our best to ensure that we are issuing certificates to the good guys and not the bad guys (as much as possible).

Browsers

Browsers are the last line of defense and are the ultimate UI when connecting to sites via HTTPS, so their representation of the site is critical to security. Over the past two years, there have been a lot of changes in the representation of sites secured with SSL, including unique treatment leading up to the SHA-1 deprecation that included yellow warnings, red locks etc.

With so many changes recently, it can be a bit confusing for businesses and consumers on what this means and how they should interpret it. I’m hoping that browsers can come to some agreed consensus on UI for SSL to make it easier for users to know which sites to trust (and for businesses to know which level of SSL they need).

For example, currently all major browsers display the company name in the URL bar, usually in green, when a site uses an Extended Validation (EV) SSL Certificate. This simple, common UI makes it easy for users to see the company operating the site to help distinguish it from impostor or phishing sites. In my opinion, it would be great to see a similar approach taken for Domain Validated (DV) and Organization Validated (OV) SSL Certificates as well – some common UI treatment to help users know if the site is using DV or OV, with OV ideally indicating higher assurance due to the additional validation checks required to get the certificate.

How Does GlobalSign Work with the CA/Brower Forum in Order to Set the Rules and Regulations for a Trusted Internet?

We’re one of the many participants that work together on defining new standards and new requirements. There have been two areas where we have been heavily involved recently:

1. Domain Validation Methods

First, we were very active in defining the updated domain validation methods that were passed in Ballot 169. We participated in the validation working group for over a year to define these domain validation methods with the goal of improving the overall security of them. We tightened up the security within the list of methods and removed the loophole that allowed CAs to use their judgement is coming up with “equivalent” methods.

2. Maximum SSL Validity Periods

We were also involved in discussions and ballots related to reducing the maximum validity period of SSL Certificates. The ballot, put forth by Google, to reduce the validity period to one year was defeated after a long debate but we understand the value of validity periods shorter than three years.

In response, we helped put forth a ballot to reduce the maximum validity period to two years, which was recently passed. We think this strikes a good compromise between the risks of longer validity periods and the impact on the enterprises who need to manage the certificates and more frequent renewals.

What Goes into Setting New Requirements?

Anyone in the CA/Browser Forum can put forth ideas for discussion to the membership base. Once general consensus is reached that the proposed change will benefit security or operations in some way, the individual can put forth a ballot with the detailed change defined. This entails adding a clear description of the problem, how the proposed change will solve it and an annotation or red line over the old requirement.  

There is at least one week of discussion and then the ballot moves immediately into the one-week voting period, assuming there are no substantial changes during the discussion period. More complex topics are often discussed at the face-to-face meetings held three times a year, where you can get a lot of the key participants in the room and have an active discussion on the pros and cons and what people would like to see as a suggested or recommended change.

Are There Other Upcoming Changes We Should Be Aware Of?

You can actively monitor the current initiatives and ballots or the public email list to keep up to date. 

Here are two upcoming changes that you should be aware of:

1. Certificate Authority Authorization (CAA)

The first is the mandatory implementation of Certificate Authority Authorization (CAA) by CAs prior to September 7, 2017.  Domain owners may create CAA DNS records that list the CAs they permit to issue certificates to the domain. 

In this model, if a domain had a CAA record, or records, and none of those records contained globalsign.com as a permitted issuer, then GlobalSign would be prohibited from issuing a certificate to that domain (or subdomain). CAA has been optional for several years but the full benefit of CAA can’t be realized until all CAs implement it. Until all CAs implement this, attackers can request certificates from those CAs that have not yet implemented CAA.

2. Certificate Transparency (CT)

Google has required Certificate Transparency (CT) for EV Certificates since early 2015 and they are expanding this to all SSL Certificates as of April 2018. The previously announced date was October 2017, but was recently changed. While this is not a CA/Browser Forum requirement, it is a global CA requirement if they want their certificates to be trusted by the Google Chrome browser. 

The six month delay will help improve the maturity of the CT logging infrastructure.  We’ve seen some CT logs come online and then fail, which can result in some certificates losing their qualified status and site visitors seeing scary “non-secure” alerts.

The new requirement means everyone who needs an SSL Certificate to be trusted by Chrome (which currently has over 60% market share), will have to use certificates that are compliant with the Google CT policy. Some organizations who may not want to publicly publish their certificates will need to decide on the best course of action. They might not issue publicly trusted certificates that are compliant with the Google CT policy and their employees might not use the standard release of Chrome, or they may need to obtain certificates from a private hierarchy. GlobalSign has a solution for this called IntranetSSL, if you need it.

So there you have it – the lowdown on the “mysterious” CA/Browser Forum…not so mysterious, right? If you want to know more about the CA/Browser Forum or about how its Baseline Requirements and standards affect you, just ask!