Your connection is not private error: Why does an SSL certificate warning appear, and how can you fix it?

NET::ERR_CERT_DATE_INVALID: Has it expired, or is the clock wrong?

NET::ERR_CERT_DATE_INVALID indicates that the certificate’s validity dates do not cover the date seen by the device. There are two reasons: either the certificate really has expired, or the visitor device’s clock is incorrect. The easiest way to distinguish them is to open the site on another device with the correct time.

If every device shows the same error, the certificate has expired. If Your connection is not private appears suddenly without any changes to the site, the most likely scenario is automatic renewal having failed silently for some time. Because the certificate works until its last day, renewal trouble is noticed only on the day it expires.

Visitor-side clock problems are more common on old computers with exhausted batteries, phones with manually changed clock settings, and devices with automatic time synchronization disabled. In this case, the site owner cannot do anything; setting the device’s date and time to automatic removes the warning.

Why did the free SSL certificate fail to renew automatically?

Free certificates are short-lived, and every renewal must be automatically verifiable; if validation fails, the certificate expires without renewal. Let’s Encrypt’s FAQ page states that default certificates are valid for 90 days and recommends renewing 90-day certificates every 60 days. A substantial proportion of free certificates offered by hosting companies use this infrastructure.

During renewal, the certificate authority checks that the domain still points to that server. According to Let’s Encrypt’s Challenge types documentation, the commonly used HTTP-01 validation operates only over port 80. Frequent causes of stalled automatic renewal are as follows:

• The domain’s DNS record has moved to another server or new hosting, while the old server is trying to renew.
• A CDN or security layer has been placed in front, preventing the validation request from reaching the server.
• A security plugin or server rule blocks access to .well-known.
• The certificate was originally issued only for the non-www address, leaving subsequently added subdomains outside its coverage.
• The hosting package or domain registration has not been renewed.

Another important change: Let’s Encrypt, as stated in its announcement, stopped expiration warning emails on June 4, 2025. The reminder previously sent before expiration no longer arrives; monitoring must take place through the hosting provider or a separate monitoring arrangement. When the domain registration itself expires, the problem begins with domain resolution failing before the certificate becomes relevant.

Certificate lifetimes are getting shorter

The CA/Browser Forum, the joint body of browsers and certificate authorities, adopted a schedule gradually reducing the maximum lifetime of publicly trusted certificates; the schedule reaches 47 days on March 15, 2029. Let’s Encrypt also, in its transition from 90 to 45 days plan, announced that default certificates would move to 64 days on February 10, 2027, and 45 days on February 16, 2028. The same announcement states that a fixed 60-day renewal interval will no longer suffice. The detailed schedule is in the SSL guide; for site owners, it means manual renewal is becoming increasingly impractical.

www versus non-www address mismatches and missing intermediate certificates

ERR_CERT_COMMON_NAME_INVALID indicates that the certificate does not cover the address opened; the most common example is a certificate issued only for alanadi.com, leaving www.alanadi.com out. A certificate can cover multiple names, but those names are determined when it is issued. Visitors entering an uncovered address see the warning.

Typical site-side causes of this code include issuing a certificate for only one of www and non-www, subsequently adding a subdomain such as a store or blog, and DNS accidentally pointing to a server hosting another website. In the last case, the browser sees another domain’s certificate on that server. The solution is to reissue the certificate to cover every address used and set a 301 redirect to a single preferred address.

Self-signed certificates and incomplete chains

NET::ERR_CERT_AUTHORITY_INVALID indicates that the certificate cannot be linked to an authority trusted by the browser. If no certificate is installed for the domain, some servers present a self-generated, self-signed certificate, which the browser rejects. If an intermediate certificate file is omitted when manually installing a paid certificate, the chain remains incomplete; the site may open normally in some browsers while warning on certain devices. This “it works for me” misconception is the most typical sign of an incomplete chain.

How do you check certificate status?

Who the certificate was issued to, who issued it, and when it expires can be seen with a few browser clicks. In Chrome, click the site information icon on the left of the address bar and open the certificate viewer through connection details. Read three pieces of information here:

1. Issued name and alternative names: Domains covered by the certificate; both www and non-www addresses should be listed.
2. Issuer: The authority issuing the certificate; if the server’s own name appears, the certificate is self-signed.
3. Validity dates: The start and expiration dates; if only a few days remain and no renewal has occurred, automatic renewal may have stalled.

The browser shows only what that device sees; this distinction matters if Your connection is not private appears on only one device. Free online SSL testing tools scan the server externally; they list chain completeness, supported protocols, and covered names in one report. Problems such as missing intermediate certificates that browsers may hide are easiest to spot through this type of scan.

How do you reinstall a certificate through the hosting panel?

For websites using free certificates, reinstallation usually takes place in the hosting panel’s SSL/TLS or security section. Panel names and menus vary by company, but the general sequence is the same:

1. Check that the domain and www DNS records point to this server; a certificate cannot be obtained for an address pointing to the wrong server.
2. View the domain’s current certificate status and covered names in the panel.
3. Request the free certificate again for every address used, including the main domain and www.
4. If a CDN or proxy is used, check that layer’s certificate and encryption mode too.
5. Enable permanent HTTP-to-HTTPS redirection and clear caches.
6. Verify the result by reopening the site in a private window and on a different device.

For paid certificates, install all three files from the provider together: the certificate, private key, and intermediate certificate. If the intermediate is omitted, the warning continues on some devices.

The certificate was renewed, but there is no padlock: Mixed content

If the certificate is valid but no padlock icon appears, the page may still request some files through http:// addresses. Google’s web.dev Mixed content explanation defines this as a page opened over HTTPS loading subresources over HTTP and states that most browsers now block such content. Remediation steps are in the SSL guide’s mixed content section.

What should visitors do if they see this warning?

The safest approach for visitors is not to bypass the warning and to contact the website through another channel. The “Advanced” button on Chrome’s warning screen may allow entry anyway; however, because the connection is unverified, this route is considered risky especially on login, payment, and form pages. Chrome’s connection security page also recommends not entering personal information on insecure pages.

• Check the device’s date and time; if incorrect, enable automatic settings.
• On public networks such as cafes or hotels, complete the network’s login page first, then try the website again.
• If the warning appears on another device and connection too, the problem is with the site; do not enter passwords or card details.
• Notify the business by phone or email; many site owners learn about the problem from visitors.

Checkout security is particularly important on e-commerce sites; this subject in the SSL, HTTPS, and secure payments guide is covered.

How does a site not secure warning affect trust, sales, and SEO?

A site not secure warning primarily affects clicks and conversions because it turns visitors back before they see the content. A full-page warning presents the “go back” option first; visitors must take an additional step to enter the website. Every visitor arriving from an ad, search result, or shared link encounters the same screen.

For SEO, HTTPS has long been a standard recommended by Google. In its 2014 HTTPS ranking signal announcement, Google announced that it had begun using HTTPS as a lightweight ranking signal. The current Page experience documentation, meanwhile, lists HTTPS among page experience topics, notes that factors other than Core Web Vitals do not directly raise rankings on their own, and states that Google always aims to show the most relevant content.

In practice, losses often arrive before a ranking decline: even if the site keeps its ranking, visitors clicking through see the warning and leave. Certificate problems therefore belong among failures that should be resolved on the day they are noticed. If the site will not open at all and the issue appears broader than the certificate, the Website not opening guide also covers server and domain-side causes.

Manual renewal or automatic renewal with monitoring?

The lasting solution is automatic certificate renewal plus separate expiration-date monitoring; manual renewal becomes unsustainable as certificate lifetimes shorten. Common practice installs a certificate once and forgets it; the problem is noticed only when a warning appears. Under a maintenance routine, renewal runs automatically and the schedule is checked separately.

In our annual maintenance process, SSL certificate and domain expiration dates are monitored on the same calendar; the certificate is checked separately after DNS or hosting changes.

Common mistakes and the correct method

The most time is lost in certificate failures through temporary interventions instead of lasting solutions:

• Asking visitors to bypass the warning through “Advanced”: Damages trust and guides visitors toward a risky habit; the correct route is fixing the certificate.
• Renewing manually without investigating the cause: The rule preventing renewal remains, and the problem recurs in the next cycle.
• Obtaining a certificate only for the non-www address: Visitors arriving through www see a warning.
• Not checking the certificate after moving hosting: The certificate on the old server does not automatically transfer to the new server.
• Downloading a “free SSL” file from unknown websites: Obtain certificates only through the hosting panel or a trusted certificate authority.

When should you consult a specialist for Your connection is not private?

Specialist support saves time if reinstallation through the panel does not remove the warning or the certificate fails again every renewal cycle. The following particularly require systematic review: sites behind a CDN or proxy, multiple subdomains, recently migrated hosting, e-commerce sites accepting payments, and unfamiliar redirects appearing alongside certificate trouble.

For hosting, the package’s technical scope, including disk, email, backups, and SSL, and renewal conditions are specified in the written quotation; details are on the hosting prices page, and hosting costs 2,000 TL annually. If certificate, domain, update, and security monitoring are to be handled together, the annual WordPress maintenance and updates service makes this an ongoing process. WordPress maintenance costs 500–2,000 TL per month depending on the site’s size and scope.