If your association uses a single SSL certificate for both your website and for authenticating servers, VPN connections, or API integrations, a policy change from Google Chrome is about to break that setup. Starting March 15, 2027, Chrome will reject publicly trusted certificates that include both server authentication and client authentication capabilities.
This is a technical change with practical consequences. Here is what is happening, why it matters for associations, and what you need to do before the deadline.
What Are Dual-Use Certificates?
Every SSL/TLS certificate contains a field called Extended Key Usage (EKU) that defines what the certificate is allowed to do. The two most common EKU values are Server Authentication (the certificate can identify a web server to browsers) and Client Authentication (the certificate can identify a client to a server, used in mutual TLS and other machine-to-machine authentication).
For years, most certificate authorities issued certificates with both EKUs included by default. A single certificate could serve your website over HTTPS and simultaneously authenticate your server to an API, a VPN gateway, or another system that required mutual TLS. This was convenient but created security concerns that the industry is now addressing.
What Is Changing
The Google Chrome Root Program, which governs the certificate authorities that Chrome trusts, is phasing out dual-use certificates in two steps:
June 15, 2026: Any new intermediate certificate authority (subordinate CA) added to Chrome-trusted hierarchies must be dedicated to server authentication only. Certificate authorities can no longer create new intermediates that sign both serverAuth and clientAuth certificates.
March 15, 2027: Every newly issued leaf certificate (the certificate installed on your server) must contain only the Server Authentication EKU. Chrome will reject publicly trusted TLS certificates that still carry the Client Authentication EKU. Affected HTTPS connections will fail.
Existing certificates issued before these dates will continue to work until they expire. But once your current dual-use certificate reaches its expiration date, you will not be able to replace it with another dual-use certificate from a publicly trusted CA.
Why This Matters for Associations
Most association websites are not directly affected. If your website simply serves pages over HTTPS and your hosting provider manages your SSL certificate, nothing changes for you. The hosting provider will issue a serverAuth-only certificate on your next renewal, and your site will work exactly as before.
The risk is in custom integrations and enterprise configurations that many associations do not even realize depend on dual-use certificates:
AMS integrations using mutual TLS. Some association management systems authenticate API connections using certificate-based mutual TLS. If those connections use your website's SSL certificate for client authentication, that setup will stop working when the certificate is renewed after March 2027.
VPN and remote access. Organizations that use certificate-based VPN authentication sometimes reuse their public web certificate. After the deadline, you will need a dedicated client authentication certificate from a private certificate authority or an enterprise PKI setup.
Unified communications. Systems like Cisco Webex, on-premises Skype for Business, and certain Microsoft Exchange configurations have historically used dual-EKU certificates. Cisco has published specific guidance urging customers to separate their certificates before the deadline.
Payment processing and financial integrations. Some payment gateways and banking APIs require client certificate authentication for API calls. If these use your public TLS certificate, they need to be migrated to a separate client certificate.
What to Do Before March 2027
Step 1: Audit your certificates. Identify every SSL/TLS certificate your organization uses. Check the Extended Key Usage field on each one. If a certificate lists both "TLS Web Server Authentication" and "TLS Web Client Authentication," it is a dual-use certificate that will be affected.
Step 2: Map where client authentication is used. For each dual-use certificate, determine whether the client authentication capability is actually being used. In many cases, the clientAuth EKU was included by default but never relied upon. If nothing in your infrastructure uses client authentication, you have no action to take beyond normal certificate renewal.
Step 3: Separate your certificates. If you do rely on client authentication, obtain a dedicated client authentication certificate. This is a separate certificate specifically for authenticating your server or application to other systems. Your certificate authority or a specialized PKI provider can issue one. Your web server continues to use a standard serverAuth-only TLS certificate.
Step 4: Update your integrations. Reconfigure any systems that use the old dual-use certificate for client authentication to use the new dedicated client certificate instead. Test thoroughly. Do this well before the March 2027 deadline so you have time to troubleshoot.
Step 5: Document and communicate. If your association works with third-party vendors for AMS integration, payment processing, or communications infrastructure, notify them about the change. Ask whether their systems are prepared for serverAuth-only certificates. The vendors who serve the association space should already be aware, but verifying is better than assuming.
The Connection to Certificate Lifespan Reduction
This dual-use certificate ban is happening alongside the CA/Browser Forum's separate initiative to reduce SSL certificate lifespans to 47 days by 2029. Together, these two changes represent the most significant shift in SSL certificate management in over a decade.
The message from the browser vendors is clear: the era of buying a certificate once a year and forgetting about it is over. Certificate management is becoming an ongoing operational responsibility that requires automation, monitoring, and technical expertise.
For associations without dedicated IT staff, this is one more reason to work with a web partner who handles infrastructure management as part of an ongoing relationship rather than as a series of one-off support requests.
Our partnership plans include complete certificate lifecycle management, from monitoring expiration dates to configuring automated renewals to separating server and client certificates when your integrations require it. Your staff should never have to think about certificate EKUs.
Stop Fighting With Free Platforms
Our partnership plans give associations and nonprofits a dedicated web team without the overhead of hiring one. From ongoing maintenance to full-scale builds, every plan includes strategy, development, and support tailored to organizations like yours.