The dangers of using an expired SSL/TLS certificate

What are SSL/TLS certificates?

IBM defines SSL/TLS certificates as a digital certificate “employed by a web server or domain name [that] contains public encryption keys that secure the connection to prevent unauthorized third parties from intercepting data while it is in transit and to validate the website's authenticity.”

An SSL/TLS certificate has three main purposes:

• Authentication: Proving the identity of the server
• Encryption: Safeguarding data in transit
• Integrity: Preventing tampering or interception

Understanding the risks of an expired certificate

When a certificate expires, all three protections immediately break down. Browsers warn users that the site is unsafe; APIs begin rejecting connections; encrypted sessions can no longer be established securely; and attackers may exploit the lapse.

Consequently, the security, compliance, and trust infrastructure it provides no longer exists. It can result in data breaches, service outages, regulatory violations, and long-term damage to user trust.

A 2025 study on TLS in healthcare web applications explains that many healthcare websites suffer from certificate-related weaknesses. More specifically, “17% had issues such as impending certificate expiry (within 30 days) or incomplete certificate chains.” 

If nearly one in five healthcare websites are close to expiry without remediation, certificate mismanagement is a widespread security gap.

What happens when a certificate expires

An expired certificate is, by definition, a weak implementation, because the trust model it depends on has failed. Moreover, “Weak TLS implementations can lead to data interception, regulatory non-compliance, trust erosion, system downtime, and financial penalties.” 

1. Browsers block or warn users

When an email system uses a web portal, an expired certificate immediately triggers full-screen browser warnings. Staff cannot log in, and many will not bypass the warning. In a healthcare organization, this could interrupt patient updates or critical scheduling information.

For example, if a hospital’s Outlook Web Access certificate expires, clinicians trying to view discharge instructions or consult notes find themselves locked out, with the browser insisting the site is unsafe. Communication slows instantly, and patient care coordination is disrupted.

2. APIs and mobile apps fail

Most email access happens through mobile or desktop clients, so clients will refuse expired certificates outright. Messages stop syncing, authentication breaks, and users see errors.

For example, if a nurse uses their mobile app for shift updates and patient notifications, the app will stop delivering messages since the TLS handshake fails, and the app cannot verify the server’s identity.

3. Encryption breaks

Email encryption protocols like SMTPS, IMAPS, and STARTTLS all depend on valid certificates. If a certificate expires, encrypted channels cannot be created and queue mail indefinitely, bounce messages, or fall back to unencrypted transmission if misconfigured. 

An example is a healthcare organization using a secure outbound encryption gateway. When its certificate expires, no encrypted emails can be sent, and prescription updates, lab results, and referral letters will pile up in server queues.

4. Attackers exploit the lapse

Attackers take advantage of the security gap, launching spoofing or MitM attacks, sending fake “IT support” messages, or redirecting users to fake login pages. 

For instance, if an attacker sees the email certificate expire, they could send users a phishing email with a malicious “temporary login link,” tricking staff into inadvertently handing over their credentials.

5. Reputational and financial fallout

According to the TLS study, “Patients and partners may lose confidence in healthcare providers that fail to meet modern security standards.” A certificate warning communicates incompetence, poor security hygiene, and potential danger. 

For example, if a hospital’s patient email portal suddenly shows a red browser warning because its certificate has expired, patients trying to view test results may assume the site has been compromised. Some refuse to log in, while a partner clinic pauses data sharing until the issue is fixed, making the hospital appear careless with security.

6. Service outages and downtime

Major outages have occurred historically due to certificate expirations. For example, in 2020, Microsoft Teams reported an outage due to an expired SSL certificate, leaving millions of users unable to sign in or use Teams at all.

7. Regulatory penalties

Certificate failures can violate national healthcare and cybersecurity frameworks, including HIPAA. Expired certificates directly contribute to non-compliance, since encrypted, authenticated transmission is mandatory.

Therefore, “Failing to comply with these frameworks can result in hefty fines… reputation damage… [and] operational restrictions.”

Why expired certificates can be detrimental to healthcare

The TLS study shows that healthcare systems are already under strain due to uneven TLS maturity, with “27% still allowed fallback connections to TLS 1.0 or TLS 1.1… despite both being deprecated.” 

Expired certificates compound these existing weaknesses since “Healthcare systems are uniquely vulnerable… making them prime targets for cyberattacks.” 

The study warns that when a certificate expires:

• Telemedicine sessions may fail
• Electronic health records (EHR) access breaks
• Patient portals become unreachable
• Backend integrations fail
• Attackers can spoof healthcare portals to steal credentials or PHI.

How attackers exploit expired certificates

Man-in-the-Middle (MitM) impersonation

Expired certificates make MitM attacks easier since the browser cannot confirm a site’s identity. It allows attackers to intercept traffic, present fraudulent certificates, and redirect patients to malicious look-alike sites, avoiding security barriers.

Phishing and spoofing

An expired certificate removes the visual cues users rely on to confirm authenticity. When the legitimate website already shows a security warning, attackers can clone the site, making fake healthcare login pages more convincing. 

Downgrade attacks

The TLS study warns that “TLS 1.0 and 1.1 should be explicitly disabled to prevent downgrade attacks.” However, when a certificate expires, some systems attempt fallback behaviors that undermine security. Servers may fall back to insecure temporary connections, revert to HTTP, renegotiate using older TLS versions, or accept weaker cipher suites, creating vulnerability points.

Session hijacking

If expired certificates force a system into insecure fallback modes (particularly HTTP), attackers can manipulate or inject traffic, allowing them to capture or take over a user’s authenticated session since encryption wasn’t established.

Automation exploits

Sophisticated attackers can scan the internet for expired certificates, soon-to-expire certificates, or broken certificate chains. Systems with these flaws are automatically flagged as weakened targets, making them far more likely to be exploited during broad sweeps for vulnerable infrastructure.

For example, in 2024, when researchers from watchTowr Labs bought the expired WHOIS domain for the .mobi TLD and set up a rogue server serving fake ownership records. Some certificate authorities still relied on this old WHOIS server for Domain Control Validation, allowing the researchers to request TLS/SSL certificates for domains they didn’t own.

When one certificate fails, whole systems fail

Given our highly interconnected healthcare systems, a single expired certificate can cascade through the environment, breaking mobile apps, API integrations, internal dashboards, EHR systems, authentication layers, cloud services, microservices that depend on mTLS, and even telemedicine video engines. 

Expired certificates disrupt the trust layer holding these systems together, resulting in systemic, rather than isolated, failures. The TLS study also notes, “… that while healthcare platforms are generally aware of HTTPS best practices, implementation maturity varies significantly,” and certificate expiration is a sign of low maturity.

How to prevent certificate expiry

Researchers in the TLS study suggest that IT security teams, “Maintain valid certificates… monitor expiry dates and ensure proper chain configuration; enable OCSP stapling or use short-lived certificates.”

However, with the new 47-day maximum validity rule for TLS certificates, the window for renewal is much shorter than the traditional 90-day or longer lifespans, making it more likely for expired certificates to go unnoticed. In healthcare, this may result in failed TLS handshakes with external mail servers, causing emails to be converted to less secure methods or bounced.

The risk is further compounded if some servers do not support OCSP stapling or the updated certificate chain, potentially creating compatibility issues and disrupting secure email communication. 

Taking these steps will also result in increased operational load for IT teams trying to manually track and renew certificates on hundreds or thousands of email servers.

Instead, organizations must use Paubox’s HIPAA compliant email solution, which eliminates obsolete TLS protocols. It allows users to send emails securely, automatically converting messages and attachments to the Paubox Secure Message Center (SMC) whenever a recipient’s mail system does not support TLS, uses an expired certificate, or relies on a self-signed SSL certificate.

For example, if a doctor sends a patient’s lab results and the recipient’s clinic mail server uses TLS but has a self-signed SSL certificate, the email is automatically redirected to the SMC. 

As a result, the patient’s protected health information (PHI) is never sent over insecure or untrusted connections, regardless of their mail system configuration. 

Similarly, if a patient’s mail server has an expired SSL certificate, like one that has surpassed its 47-day maximum validity window, the email is converted to the SMC. 

Ultimately, this patented solution keeps PHI secure and upholds HIPAA compliance. It allows healthcare providers to communicate securely and confidently, without worrying about certificate errors or encryption gaps.

FAQs

What is a self-signed SSL certificate?

A self-signed SSL certificate is a certificate that is generated and signed by the server itself instead of a trusted certificate authority (CA). While it still uses encryption, it is not automatically trusted by browsers, email servers, or other clients. Consequently, users may see security warnings or the connection may be rejected altogether. 

Self-signed certificates are sometimes used for internal testing or private networks, but are not appropriate for healthcare organizations. They don’t verify the server’s identity, so they cannot transmit protected health information (PHI) securely, violating HIPAA regulations.

What is a certificate chain?

A certificate chain links a server’s SSL/TLS certificate to a trusted root authority through a series of certificates. Intermediate certificates connect the server’s certificate to a root certificate that clients recognize for verification.

Misconfigured chains can lead to errors, failed TLS handshakes, or rejected emails, even if the server’s certificate itself is valid.

What is OCSP stapling?

Online Certificate Status Protocol (OSCP) stapling is a way for a web or email server to prove that its TLS certificate is still valid without requiring clients to contact the certificate authority directly. The server sporadically requests a time-stamped OCSP response from the CA and “staples” it to the TLS handshake when a client connects. 

“Under OCSP stapling, the web server provides the web client (i) with the certificate, and (ii) with a signed confirmation that the certificate has not been revoked,” as evidenced in a research article on the Design and Implementation of a Compressed Certificate Status Protocol.

In summary, “OCSP stapling is fast, does not force the client to contact any third-party services, and has a low overhead.”