Beginning September 1, 2020, Apple’s Safari browser will no longer trust SSL/TLS certificates issued for longer than 398 days, which is the equivalent of one year plus the renewal grace period. Apple cited its “ongoing efforts to improve web security” in the announcement earlier this year. The change affects the full lineup of Apple platforms:
This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS. Additionally, this change will affect only TLS server certificates issued on or after September 1, 2020; any certificates issued prior to that date will not be affected by this change.
Apple will begin enforcing the change immediately, which means it will deny connections to TLS servers that don’t meet the new requirements. After Apple’s announcement, both Google and Mozilla contributors moved to propose their own implementations that cap certificate validity at 398 days.
All of the major certificate authorities are falling in line, changing their offerings to conform with the new one year limit. This includes CA market leader IdenTrust, which accounts for roughly 52% of SSL certificates. DigiCert, a CA that captures 20% of the market, published a dry note of compliance, emphasizing the burden it places on certificate users:
Why did Apple unilaterally decide to enforce a shorter certificate lifetime? Their spokesperson said it was to “protect users.” We know from prior CA/B Forum discussions that longer certificate lifetimes proved to be challenging in replacing certificates, in the case of a major security incident. Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats. Short-lived certificates improve security because they reduce the window of exposure if a TLS certificate is compromised. They also help remediate normal operational churn within organizations by ensuring yearly updates to identity such as company names, addresses and active domains. As with any improvement, shortening of lifetimes should be balanced against the hardship required of certificate users to implement these changes.
The idea behind the change is that certificates with shorter life cycles are more secure, as compromised keys would expire on shorter timeframes. The new one-year expiration forces hosts and certificate providers to make automation a high priority. In fact, this is one of the reasons Let’s Encrypt’s free certificates already have a short 90-day life cycle. It was put in place years ago to encourage automation so that shorter lifetimes are no less convenient than longer ones.
Let’s Encrypt recommends subscribers renew every sixty days and may even consider recommending shorter lifetimes once automated renewal tools are more widely adopted. This may be happening sooner than anticipated now that Apple’s policy is forcing change across the industry.
Many WordPress users make use of Let’s Encrypt certificates using a plugin like WP Force SSL & HTTPS Redirect (100k+ active installs), SSL Zen (20k+ installs) or WP Encryption (20k+ installs). Some plugins have automatic renewal built in, but some offer it as part of a commercial upgrade. Others rely on hosts to perform renewals.
Although most website owners will not need to take action, the shorter certificate life cycle may can become a hassle without automated certificate management in place. It may also affect client billing with different options available from hosts and certificate authorities. If you manage websites for clients whose sites previously relied on certificates with longer life cycles, you will want to make sure to have some form of automated certificate management set up when the change goes into effect.
Like this:
Like Loading…
Keep reading the article at WordPress Tavern. The article was originally written by Sarah Gooding on 2020-08-17 19:08:43.
The article was hand-picked and curated for you by the Editorial Team of WP Archives.