SSL/TLS certificates issued by trusted Certificate Authorities (CAs), either public or private, are used to authenticate a single domain in public facing websites. Organizations with a handful of public domains and subdomains would have to issue and manage an equal number of digital certificates, increasing the complexity of certificate lifecycle management. The good news is that there is a solution to bypass this burden.
Wildcard certificates promise simplicity, but are they the solution to all our prayers?
TLS certificates serve many purposes. Primarily, they enable encrypted sessions between clients and the websites and prove that the site is not a malicious imposer. A good security practice is to renew key pairs frequently, which should happen whenever you get a new certificate.
Since 2005, the CA/B Forum has established the rules on how TLS certificates should be issued, managed, and validated. This volunteer organization is made up of two groups:
- Certificate Authorities (CAs) — such as IdenTrust, DigiCert, and GoDaddy;
- Browser developers — such as Google, Apple, Microsoft, and Mozilla.
Browsers and CAs usually discuss and vote on rule proposals until they reach a majority agreement, and then all members apply the final rule.
Despite a decision by the CA/B Forum not to limit certificate lifespans to one-year, Apple made a unilateral decision in February to limit the lifespan of accepted TLS certificates to just 398 days, starting September 1st.
Google and Mozilla Join Apple's Decision
Chrome joins Apple in limiting public TLS certificates to 398 days starting Sept 1st.— Dean Coclin (@chosensecurity) June 10, 2020
It looks like the browsers won this round. On July 9, 2020, Mozilla Security Blog published it will also be reducing TLS certificate lifespans to 398 days. Thus, effective Sept. 1, 2020, Mozilla, Google, and Apple will no longer trust any newly issued certificates with a valid lifespan of longer than 398 days.
Now the spotlight is on Microsoft, which is expected to decide on the issue soon. Keep in mind, however, Microsoft Edge uses Chromium as its browser engine.
Regardless, the major public CA vendors have been quick to adapt, no longer offering two-year public TLS certificates. After all, they really have no choice with the vast majority of web users opting for the Chrome and Safari browsers.
Mozilla has expressed the belief that this change is crucial to maintain a secure web, as it:
- Promotes greater crypto agility as vulnerable certificates will automatically phase out in less time.
- Limits the vulnerability of a website to intrusion as the private encryption keys will periodically be forced to update.
- In the cast of stolen TLS certificates, the amount of time a threat actor can use would be limited by a one-year validity.
- Prevents hosting providers or third parties from continuing use of certificates even after a web service has switched providers or is no longer actively using the certificate.
It is true, a compromised key could enable an attacker to intercept secure communications and/or impersonate a website until the TLS certificate expires. However, certificate subscribers frequently forget how or when to replace certificates, causing service outages from unexpected expiration.
And while this aims to make everyone more secure, if your internal management process does not leverage certificate automation, your company may actually become less secure and more prone to outages. If you’re still using manual processes (e.g. spreadsheets) to manage these certificates, your workload has virtually doubled overnight. These workload increases also create more opportunities for misconfiguration of those certificates.
Expired Certificates is a Massive Problem
They cost companies millions of dollars due to outages every year. On top of that, more frequent expired certificate warnings may result in web visitors becoming more comfortable bypassing the error messages.
Furthermore, the significant reduction in the validity period will result in more frequent certificate issuance. This will lead to substantial increases in the annual fees for certificate consumers due to increased costs to businesses maintaining the certificates (especially for OV and EV certificates).
These are mostly the long-term effects that this change will bring, but CA, website owners, and even end-users could be affected immediately after the Sept. 1 change occurs.
This means some websites and apps may stop working as expected on Apple, Google, and Mozilla applications if the companies behind them are unprepared to handle more frequent renewal of certificates to keep their services up and running.
Moving forward your CA vendor will no longer offer two-year public TLS certificates. Failure to prepare for shorter certificate lifecycles means your web visitors will face an error message, causing immediate impacts to your brand and revenue.
Mozilla Firefox – insecure website message
Google Chrome – insecure website message
Apple Safari – insecure website message
Do we need to replace our existing two-year TLS certificates with one-year certificates?
This change applies only to new TLS certificates issued on or after Sept. 1, 2020. Previously issued certificates with a lifespan of two years, will not be affected, and you can continue to use it until its original expiration date. However, any certificates issued after Sept. 1, 2020, will be valid for a maximum of one year.
What does this mean for TLS secured website owners?
This will lead to increases in administrative overhead as web site administrators will need to keep a closer watch on renewal dates as certificates will expire more frequently. For companies that host numerous websites, this can be a major problem until automated procedures are implemented or modified.
Some Good News
You will still be able to buy multi-year subscription plans. Commercial certificate authorities (CAs) are rolling out such plans to enable their customers to continue to take advantage of multi-year discounts after the Sept. 1st changes. Basically, the more years you sign up for, the bigger the discount per year. This could save long term certificate costs; however, you will still need to re-deploy your certificates each year before they expire.