SSL and security
SSL installation, configuration, and the new 200‑day certificate rules
SSL is one of those parts of a website that should simply work, but in practice it often causes confusion, broken padlocks, or unexpected downtime when something is misconfigured. I have spent many hours installing, configuring, and fixing SSL certificates across different environments, from shared hosting and control panels to raw servers, VPS instances, and dedicated machines. In this article I explain how I approach SSL work, what common padlock issues usually mean, and why the new industry rule that limits SSL certificates to a maximum of 200 days matters for website owners and server administrators.
What I offer when it comes to SSL
I handle SSL as a complete service, not just a one-time installation. That includes choosing the right type of certificate for the project, installing it correctly on the server or hosting account, configuring HTTPS properly, and fixing any padlock or mixed-content issues that appear after the change. I can set up SSL in any environment. That includes standard shared hosting with cPanel or Plesk, custom VPS setups, dedicated servers, cloud instances, and more complex stacks where multiple domains and subdomains need to be covered. Whether the certificate comes from Let’s Encrypt, a commercial CA, or a wildcard or multi-domain setup, I treat the configuration as part of the overall security and performance of the site.
Why SSL matters beyond the padlock icon
SSL is not only about showing a padlock in the browser. It protects data in transit, improves trust, and is required by many modern web features and third-party services. Browsers mark non-HTTPS sites as not secure, which can affect user confidence and even SEO. A properly configured SSL setup also supports better performance through HTTP/2 or HTTP/3, enables secure cookies, and helps protect login sessions and form submissions from interception. That is why SSL should be seen as infrastructure, not as an optional extra.
Common SSL and padlock issues I fix
Even when a certificate is installed, many websites still show warnings or a broken padlock. The most common reasons are mixed content, where some resources are still loaded over HTTP, incorrect certificate chains, missing intermediate certificates, or redirects that are not fully enforced to HTTPS. I regularly fix these issues by reviewing the full page load, identifying insecure resources, adjusting theme or plugin settings, correcting server redirects, and ensuring the certificate chain is complete and trusted by all major browsers. The goal is not only to make the padlock appear, but to make sure the whole site behaves securely under HTTPS.
SSL on WordPress and Joomla websites
Most of the SSL work I do is on WordPress and Joomla websites, and the challenges are often similar even though the platforms are different. On WordPress, SSL issues frequently come from plugins or themes that hard-code HTTP URLs, legacy content with old image links, or caching layers that do not follow the HTTPS redirect properly. I fix these by updating site URLs, correcting database references, adjusting plugin settings, and ensuring the whole stack from server to theme respects HTTPS. On Joomla, SSL problems often appear after migrations, when SEF URLs or live site settings are not aligned with the new HTTPS configuration. Extensions and templates can also introduce mixed content if they reference assets over HTTP. I handle Joomla SSL by configuring the global site settings, checking SEF and SSL options, updating extension parameters, and cleaning up any hardcoded links that break the padlock. In both cases, the certificate itself is usually only one part of the puzzle. The CMS configuration, theme or template code, and plugin or extension behavior all need to be checked to make sure HTTPS works consistently across the entire site.
The new 200‑day SSL certificate validity rule
One of the biggest recent changes in the SSL landscape is the new maximum validity period for publicly trusted certificates. Starting in March 2026, the CA/Browser Forum reduced the maximum lifetime from around 398 days to just 200 days. This means new certificates issued after that date can be valid for no more than 200 days before they must be renewed. This is an industry-wide requirement that affects all major certificate authorities, not just one provider. Existing certificates issued before the deadline keep their original validity, but every new certificate from that point on must comply with the 200‑day cap. The plan is to shorten this further in the coming years, with 100‑day maximums in 2027 and 47‑day maximums by 2029. For website owners, this change means renewals will happen more often. For servers and environments without automation, it also means more operational work and a higher risk of accidental expiry if renewals are forgotten.
Why automation and proper setup matter more now
Shorter certificate lifetimes are designed to improve security by limiting the damage from mis-issuance or key compromise, and by encouraging automation. Let’s Encrypt has used 90‑day certificates for years, and many commercial CAs are now issuing certificates around the 199‑day mark to stay under the 200‑day cap. If your SSL setup relies on manual renewals, the new rules make it more important to have reminders, processes, or managed support in place. A forgotten renewal can lead to expired certificates, browser warnings, and avoidable downtime. That is why I recommend treating SSL as an ongoing responsibility, not a one-time task.
SSL setup across different environments
I install and configure SSL on a wide range of environments. On shared hosting with cPanel or Plesk, that usually means generating or importing the certificate, binding it to the correct domain, enforcing HTTPS redirects, and checking for mixed content. On VPS and dedicated servers, the work is more low-level. It can involve configuring Apache or Nginx directly, setting up Let’s Encrypt with ACME clients, managing certificate paths and permissions, configuring HSTS and security headers, and ensuring the setup works correctly across all domains and subdomains. I also handle more complex cases such as multi-domain certificates, wildcard certificates, load-balanced setups, and environments where the SSL termination happens at a proxy or CDN layer. The principle is always the same: the certificate must be correctly installed, the chain must be complete, and all traffic should be served securely without warnings.
Renewal planning under the 200‑day rules
With the new 200‑day maximum, renewal planning becomes more important. Certificates now need to be renewed at least twice a year instead of once, and the window for action is smaller. I help clients by setting up renewal processes that fit their environment. That can mean automated Let’s Encrypt renewals on Linux servers, managed renewals through hosting panels, or scheduled reminders and hands-on renewal support for commercial certificates. The goal is to make sure certificates are renewed before they expire, without relying on memory or last-minute fixes.
How I can help with your SSL setup
If you need SSL installed, configured, or fixed, I can handle the full process on almost any environment. That includes new installations, migrating existing certificates, fixing padlock and mixed-content issues, troubleshooting warnings, and setting up reliable renewal processes under the new 200‑day rules. I treat SSL as part of the overall security and stability of your website or server. If you want help with SSL on a VPS, dedicated server, cPanel or Plesk hosting, or a more custom stack, I can take care of the technical side so that HTTPS works correctly and stays reliable over time.