Public certificate change puts VPN & Wi-Fi at risk

Your company's Wi-Fi and VPN logs staff in with a certificate designed for websites. Public certificate authorities have stopped issuing them, and the last free ones expire in October. 

If a public certificate authority issues your organisation's certificates, they are going to expire very soon. The industry has closed that door and stopped supporting public certificates. Let's Encrypt shut it down in July, the paid providers finish in early 2027, and anything you have left is expiring now. 

Let's Encrypt issued its last client certificate on 8 July 2026. Those certificates last 90  days. The final ones expire in October. 

If that sentence means nothing to you, good. Most organisations are unaffected. Some are and have a plan. The rest do not even know it yet. 

A digital certificate is a small file that proves who and what something is with providence. When your browser shows a padlock, it has checked a certificate issued by a company called a certificate authority, and it trusts that company to have checked properly. It has also secured (encrypted) the communications channel being used. 

Every certificate carries proof of a server's identity. That is the padlock. Another piece of information that has been in many certificates proves a client's identity, meaning a laptop, a phone, a service or a machine connecting in. 

Public certificate authorities have put both permissions on the same certificate for years, so organisations used them for both jobs. They bought a certificate to secure a website, then they used the same kind of certificate to let staff laptops onto the VPN. It was cheap. It was automatic. It worked. 

It also did something nobody intended. 

When your VPN trusts a public certificate authority, it starts by trusting every certificate that authority has ever issued. Let's Encrypt has issued hundreds of millions of certificates. What keeps a stranger out is the second check, where the VPN reads the name inside the certificate and decides whether that name belongs on your network. 

Browsers do the equivalent check automatically for websites. For client certificates,  nobody does it for you. Your team configured it, or your team did not. 

Picture a lock that opens for a keyring with millions of keys, and a guard who reads the label on each one. The guard is doing all the work. But nobody is checking whether you actually hired a guard. 

Google moved to stop it. Its Chrome Root Program now requires certificate authorities in the browser's trust store to issue for one purpose only: proving a server's identity.  Apple, Mozilla and Microsoft followed. So, the client permission is being stripped out  across the industry. 

The dates differ by provider, which is where people are getting stuck. 

Let's Encrypt finished on 8 July 2026. Google Trust Services stopped accepting requests in April 2026, with no exceptions. DigiCert switched the permission off by default in  October 2025 and will remove it on 1 March 2027. Sectigo switched it off in September  2025 and will remove it in February 2027. Chrome stops allowing it altogether from 15  March 2027. 

The paid providers give you until 2027. The free ones have already finished. So the  organisations with the smallest budgets and the least PKI experience have the shortest  runway, and they are the least likely to be reading this. 

What breaks? 

Staff laptops joining the VPN with a certificate instead of a password. Company phones joining the Wi-Fi. One service proving itself to another over an API, which engineers call mutual Transport Layer Security (mTLS). Sign-on systems that check a certificate on the  

device. Build pipelines where one machine authenticates to the next. Controllers talking to each other on a plant floor. 

None of those is websites. All of them borrowed the website's identity system. 

When the old certificate expires and its replacement arrives without the client permission, the connection is refused. Nothing warns you. The laptop just does not connect. The browsers have not removed a feature. They have shut what was meant to be a locked door that has been propped open. Most of us never noticed it was propped open, because it was convenient. 

The fix is a certificate authority you run yourself. It is trusted by and issues only to your devices and your services, so the keyring holds only your keys. You decide who gets one, how long it lasts, and when it stops.

So, what does good look like? A private authority speaks the enrolment methods your devices already know, including ACME, SCEP, EST, and 802.1X with EAP-TLS for Wi-Fi.  Devices enrol themselves. Certificates renew themselves. Nobody types anything. 

Here are three questions that you can ask your security team today to help you  understand where you stand: 

1. Which of your systems log in with a certificate rather than a password? Check  VPN, Wi-Fi, APIs, build pipelines, and any equipment that talks to other equipment. 

2. Who issued those certificates? If free automated issuance appears in the answer, treat it as this month's work. 

3. When does each one expire? Not the average. Each certificate. 

None of that is technically hard. It is usually nobody's job, and that is the failure that matters. A certificate with no owner never gets migrated. It gets discovered when something stops working. 

There is one more thing that I want to leave you with. The authority issuing your client certificates will also have to issue post-quantum certificates before the end of 2030,  the deadline the Australian Signals Directorate has set for retiring today's cryptography. 

Find the certificates before they expire. Otherwise, the first warning may be the moment your people and systems can no longer connect. 

These certificates will be found in one of two ways: in an inventory now, or in an outage later.