The one-year SSL certificate has an expiration date of its own: March 15, 2026. From that date forward, no publicly trusted certificate authority, GoDaddy included, can issue a TLS certificate valid for more than 200 days. The CA/Browser Forum schedule keeps cutting from there until certificates top out at 47 days on March 15, 2029.
For mid-market organizations that buy certificates from GoDaddy, that schedule turns the GoDaddy SSL reissue policy from a once-a-year chore into a recurring operational workload. A multi-year SSL plan still buys a multi-year subscription. It does not buy a multi-year certificate, and the gap between those two things is where outages, failed audits, and broken customer logins come from.
This article breaks down what GoDaddy requires when a certificate must be reissued, why the industry is shortening certificate lifetimes, how often your team will now touch every certificate, and where the hidden certificates sit inside a VMware-powered infrastructure. It closes with a practical plan for turning certificate renewal from a calendar reminder into an automated, monitored process that holds up as validity periods keep shrinking.
Understanding the GoDaddy SSL Reissue Policy
GoDaddy, like every commercial certificate authority, separates two things that customers tend to treat as one: the subscription and the certificate. The subscription is the commercial term you pay for, frequently spanning multiple years. The certificate is the cryptographic file installed on your server, and its lifetime is capped by industry rules that GoDaddy does not set and cannot override.
When a certificate reaches the end of its maximum validity while the subscription is still active, the customer has to reissue it. GoDaddy calls this process a rekey. In practice it means generating a new certificate signing request (CSR) on the server or appliance that will hold the certificate, submitting that CSR through the GoDaddy SSL dashboard, completing domain control validation again if the prior validation has aged out, downloading the newly issued certificate along with its intermediate chain, and installing it everywhere the old certificate lived.
That last clause is the one that causes trouble. A single wildcard or multi-domain certificate may be installed on web servers, a load balancer, a reverse proxy, a firewall’s remote access portal, a mail relay, and a virtual desktop gateway. Reissuing the certificate in the dashboard takes minutes. Finding and replacing every installed copy is the real job, and for any certificate deployed outside GoDaddy’s own hosting platforms, that job sits squarely with the customer.
Three characteristics of the reissue model matter most for planning:
- Reissue happens inside the existing subscription. Your renewal date for billing and your expiration date for the installed certificate are now two different dates, and as validity shrinks, they drift further apart.
- Each reissue can trigger fresh validation. Domain control must be proven within the reuse window the industry allows, and organization validation (OV) and extended validation (EV) certificates carry their own identity revalidation clock.
- Auto-renew covers billing, not installation. Turning on auto-renew keeps the subscription alive. It does not place a new certificate on your firewall at 2 a.m. before the old one expires.
None of this is unique to GoDaddy. Every public certificate authority now operates the same way, because the rules come from the industry body that governs browser trust. What makes the GoDaddy case worth examining is how many mid-market organizations bought multi-year plans assuming the certificate itself would last as long as the invoice.
The CA/Browser Forum Schedule Driving Shorter Certificates
The CA/Browser Forum is the industry body where certificate authorities and browser makers such as Apple, Google, Microsoft, and Mozilla set the Baseline Requirements for publicly trusted certificates. In April 2025 it approved Ballot SC-081. Apple proposed the measure, and it establishes a stepped reduction in maximum certificate validity:
- Certificates issued before March 15, 2026: up to 398 days.
- Certificates issued from March 15, 2026: up to 200 days.
- Certificates issued from March 15, 2027: up to 100 days.
- Certificates issued from March 15, 2029: up to 47 days.
The chart, built from GoDaddy’s help documentation explaining why SSL certificate validity periods are changing, shows the shape of the problem. Each step roughly halves the lifetime of the step before it, and the final step lands at roughly one-eighth of the 398-day validity organizations have relied on for years.
The rationale is security, and it is sound. A shorter lifetime limits how long a compromised private key or a mis-issued certificate remains useful to an attacker. It also reduces dependence on revocation checking, which browsers have long treated as unreliable at internet scale. Google signaled the direction in 2023 when it proposed moving to a 90-day maximum, and SC-081 formalized an even more aggressive endpoint with a firm calendar attached.
For buyers, the lesson is that the shortening schedule is not a vendor pricing tactic and it is not negotiable. Every public certificate authority must comply, so switching providers does not escape it. The only variable you control is how efficiently your organization responds.
From One Reissue a Year to Roughly Eight
The second prepared chart translates validity periods into the number that matters to an operations team: how many times per year each certificate must be reissued and reinstalled. It draws on GoDaddy’s blog guidance on what shorter validity periods mean for its customers.
The arithmetic is unforgiving. At 398 days, a certificate is touched roughly once per year. At 200 days, it is touched about twice. At 100 days, the cadence moves to roughly quarterly, and at 47 days it climbs to around eight cycles per year. Those figures assume you replace the certificate on the last possible day. No responsible team does that, because a buffer is needed for validation delays, change windows, and failed installs, so the practical frequency runs higher.
Now multiply by your certificate count. Consider an organization that manages a few dozen public certificates across websites, customer portals, APIs, VPN gateways, and email infrastructure. Under the old model, that is a few dozen manual events per year. Under the 47-day model, it becomes several hundred. Each one is an opportunity for a typo in a CSR, a missing intermediate certificate, a forgotten appliance, or a change ticket that sits unapproved over a holiday weekend.
Where the Hours Actually Go
The dashboard step is the smallest part of a reissue. The labor lives in the surrounding work:
- Locating every endpoint where a given certificate is installed, including the ones nobody documented.
- Generating CSRs with the correct key type, key size, and subject alternative names.
- Completing domain control validation through DNS records, HTTP files, or email approval.
- Importing the certificate and chain into platforms that each expect a different format, from PEM files on Linux to PFX bundles on Windows to proprietary import screens on firewalls.
- Restarting or reloading services, then verifying the full chain from outside the network.
- Updating the inventory so the next cycle starts from accurate data.
At one cycle per year, a capable administrator absorbs this work without much notice. At eight cycles per year across dozens of certificates, it becomes a standing function that competes with patching, backup validation, and incident response for the same scarce hours. That is the hidden cost of the GoDaddy SSL reissue policy under the new schedule: not the price of the certificate, but the labor of keeping it installed.
Domain Validation Is the Hidden Workload
Validity is only half of SC-081. The ballot also shortens how long a certificate authority may reuse a prior validation before it must check again. Domain control validation reuse, long allowed for up to 398 days, falls to 200 days in March 2026, 100 days in March 2027, and just 10 days in March 2029. Subject identity information used for OV and EV certificates drops from 825 days of reuse to 398 days in March 2026, which means organization details must be revalidated every year.
The 10-day figure deserves attention. Once it takes effect, nearly every reissue will require a fresh proof of domain control. Teams that still rely on email-based validation, where an approval message lands in an administrative mailbox and someone has to click a link, will find that method collapsing under its own volume. The industry is already moving away from weaker approaches, and the CA/Browser Forum has acted to sunset validation methods that depend on WHOIS contact data.
DNS-based validation is the durable answer. Placing a validation record in DNS, ideally through an API rather than by hand, lets validation happen as part of an automated workflow. That, in turn, requires change control over DNS that many mid-market organizations have never formalized, especially when DNS is hosted at the registrar and managed through a shared login that three former employees once knew the password to.
A multi-year SSL plan buys a multi-year subscription. It does not buy a multi-year certificate, and the gap between the two is where outages begin.
The Outage Math: When a Missed Reissue Becomes a Business Event
An expired certificate does not degrade gracefully. Browsers present a full-page security warning that most customers will not click through, and they should not. APIs and integrations that validate certificates simply refuse to connect, which means partner data feeds, payment workflows, and single sign-on handoffs fail without a friendly error page. Mobile apps that strictly validate certificates stop talking to their back end.
The damage extends well beyond the public website. When a remote access gateway certificate expires, remote employees cannot connect. When a mail relay certificate lapses, enforced TLS between mail servers can break, and messages queue or bounce. When an internal application trusts a public certificate on a back-end service, a lapse can surface as a mysterious application failure that consumes hours of troubleshooting before anyone thinks to check the expiration date.
Large organizations have learned this the hard way. Expired certificates have caused well-publicized disruptions across major technology platforms over the years, and the root cause is almost always the same: a certificate existed outside the monitored inventory, the person who installed it moved on, and the reminder email went to an unattended mailbox. Shorter lifetimes do not create that failure mode, but they multiply the number of times it can occur.
The business translation is direct. A missed reissue on a customer portal is a revenue event. A missed reissue on a VPN gateway is a productivity event. A missed reissue on an integration endpoint is a partner relationship event. None of them are technology problems by the time leadership hears about them, and every one of them is preventable with inventory, monitoring, and automation.
Forced Reissues: Revocation Does Not Wait for Your Calendar
Scheduled expirations are predictable. Forced reissues are not. The Baseline Requirements oblige certificate authorities to revoke certificates within tight windows when problems are discovered: 24 hours for the most serious issues, such as a compromised key or a domain validation that should not have succeeded, and five days for many other compliance defects.
These rules are enforced. In July 2024, DigiCert announced it had to revoke a large population of certificates within 24 hours after discovering that a subset of its domain validations had not met the Baseline Requirements, leaving many customers roughly a day to reissue and reinstall. Separately, in 2024 Google announced that Chrome would stop trusting newly issued TLS certificates from Entrust, pushing Entrust customers to move to other certificate authorities on a compressed timeline.
Neither event involved GoDaddy, and the point is not to single out any provider. The point is that any certificate authority can face an incident that forces a mass reissue, and the customers who recover fastest are those who already reissue frequently through an automated, inventoried process. Viewed this way, short validity periods are a forcing function. They make the muscle you need for an emergency part of your normal operating rhythm.
An organization that can reissue every certificate in an afternoon has turned a potential crisis into routine maintenance.
Market Concentration and the Automation Divide
The third prepared chart, drawn from W3Techs data on certificate authority usage across websites, shows how concentrated the certificate market has become and where GoDaddy sits among the authorities that secure the web.
Two observations stand out. First, Let’s Encrypt, the nonprofit authority that issues free 90-day certificates through the ACME protocol, has become the most widely used certificate authority on the web. Its growth demonstrates that short-lived certificates work at enormous scale when issuance and installation are automated end to end. Second, commercial authorities such as GoDaddy, Sectigo, DigiCert, and GlobalSign continue to serve organizations that need OV or EV certificates, formal support arrangements, or a single vendor relationship for billing and procurement.
The real divide is not between free and paid certificates. It is between automated and manual lifecycles. ACME is an open standard published as RFC 8555, and many commercial authorities now support it or offer their own APIs. If your GoDaddy certificates are installed on systems that cannot run an ACME client, such as older appliances or applications with manual import screens, those systems become the pressure points as the reissue cadence accelerates. Confirm with your provider which automation options your specific certificate plan supports before you design a process around them.
Where Certificates Hide in a VMware-Powered Estate
Most mid-market organizations underestimate their certificate count because they think of certificates as a website concern. In a modern hybrid environment built on VMware and its ecosystem partners, certificates sit in many places that never appear on a marketing team’s renewal list:
- Remote access and virtual desktop gateways. Omnissa Horizon environments commonly front user access with Unified Access Gateway appliances, and those gateways present a certificate that every remote user’s client must trust.
- Firewall and VPN portals. FortiGate appliances and similar platforms use certificates for remote access portals, administrative interfaces, and, in many deployments, SSL inspection.
- Backup and replication endpoints. Veeam Cloud Connect, which links customer backup infrastructure to a service provider, relies on a TLS certificate to secure that connection.
- Virtualization management. vCenter Server uses certificates for its management interfaces, and many organizations replace the default certificates with ones from an enterprise or public authority.
- Messaging. Microsoft Exchange servers and on-premises mail relays present certificates for encrypted transport and client access, and secure email gateways enforce TLS policies that fail when an endpoint’s certificate is invalid.
- Load balancers, reverse proxies, and APIs. These often hold the same wildcard certificate as the public website, which means one reissue can require updates in several places.
Not every one of these certificates will be a public certificate from GoDaddy. Some use internal certificate authorities, and private certificates are not bound by the CA/Browser Forum validity schedule. The critical step is knowing which is which. A public certificate quietly installed on a management interface years ago is exactly the kind of asset that expires unnoticed.
Virtual desktop gateways deserve special attention because their failure is so visible. When desktops are delivered as a managed service such as Desktop as a Service (DaaS), the provider should own gateway certificate lifecycle as part of the service, so that a reissue deadline never becomes a Monday morning help desk flood.
Disaster recovery adds a second copy of the problem. If a recovery site runs replicated virtual machines, those replicas carry whatever certificates were installed at replication time, and recovery-side gateways or load balancers hold their own copies. A failover that brings up a workload with an expired certificate, or a DNS cutover to a recovery endpoint whose certificate was never reissued, turns a recovered system into an inaccessible one. Certificate validity belongs on every DR failover validation plan, right next to network mapping and boot order.
Mapping the GoDaddy SSL Reissue Policy to the Five Pillars
Shorter certificate lifetimes touch every dimension of infrastructure strategy. Framing the response around the five pillars keeps the conversation focused on business outcomes rather than file formats.
Simplification
Standardize on a small number of certificate types, a single inventory, and a repeatable installation method for each platform class. Consolidation helps, but it carries a trade-off: one wildcard certificate spread across twenty systems reduces purchase count while increasing the blast radius of a single missed install. The goal is not only fewer certificates but also fewer distinct ways of deploying them.
Security
Shorter lifetimes reduce exposure from compromised keys, but only if every reissue generates a fresh key pair and private keys are protected in transit and at rest. Reusing the same CSR and key across cycles quietly erases much of the benefit. Continuous external monitoring through Security as a Service (SECaaS) can flag expiring, weak, or unexpected certificates before browsers, customers, or attackers notice them.
Performance
Every reissue is a chance to modernize rather than copy forward. Current TLS configurations and efficient key types such as ECDSA reduce handshake overhead and improve the experience for users connecting from distant locations or constrained devices. A disciplined reissue process becomes a lever for retiring outdated cipher configurations that would otherwise linger for years.
Resilience
Treat a mass reissue as a recoverable incident with a documented runbook and a known recovery time. Validate that recovery environments carry current certificates, and include certificate checks in Disaster Recovery (DRaaS) testing so that failover produces a usable service rather than a running virtual machine nobody can reach.
Flexibility
Avoid hard-wiring your process to a single provider’s manual workflow. Standards-based automation lets you change certificate authorities, as Entrust customers were forced to, without rebuilding your operations from scratch. Flexibility here is insurance against events no customer controls.
A Practical Action Plan for Mid-Market IT
The March 2027 step to 100-day certificates is the practical deadline for having a working process in place. At quarterly reissue, manual effort becomes visibly painful. At 47 days, it becomes untenable. The steps below build that process in a sensible order.
- Build a complete inventory. Scan public IP space and internal networks for TLS endpoints, pull certificate records from your GoDaddy account, and reconcile the two. Every certificate needs an owner, a list of install locations, and an expiration date tracked in a system that alerts a team, not an individual.
- Separate subscription dates from certificate dates. Track billing renewals and certificate expirations as different events in your calendar and ticketing system.
- Move domain validation to DNS. Retire email-based approvals where possible and put DNS changes under documented change control, ideally with API access so validation can be automated.
- Automate where the platform allows. Use ACME clients or provider APIs on servers that support them, and identify the appliances that require manual import so they receive extra lead time.
- Set a renewal buffer. Reissue well before expiration, early enough to absorb a failed validation or a postponed change window.
- Rehearse a forced reissue. Pick a representative certificate and time how long it takes to reissue and reinstall it everywhere. Then plan as though you had 24 hours to do the same for every certificate you own.
- Add certificates to DR testing. Confirm that recovery environments present valid certificates after failover and after DNS cutover.
- Review OV and EV requirements. With identity revalidation reuse dropping to 398 days, decide whether each certificate truly needs organization validation or whether domain validation with automation fits the use case.
Few mid-market IT teams have spare capacity to absorb a new recurring workload of this size on top of patching, backups, and security operations. That is where Managed Services earns its place: certificate lifecycle becomes one more monitored, documented process run by a team that owns the outcome, rather than a reminder sitting in one administrator’s inbox.
Reframe: Certificate Renewal Is Now an Operations Discipline
For two decades, an SSL certificate was a purchase. Someone in IT or marketing bought it, installed it, and set a reminder for next year. The GoDaddy SSL reissue policy, shaped by an industry schedule that ends at 47 days, retires that model permanently. Certificates are now a continuously running operational process, closer to patching than to procurement.
That shift is not only a security improvement but also an opportunity to fix the brittle, undocumented edges of your infrastructure. The organizations that will handle 47-day certificates calmly are the ones that use the next steps on the schedule to inventory their endpoints, automate validation, and move workloads onto platforms where an experienced operations team owns the lifecycle alongside patching, backup, and monitoring. Managed Cloud Hosting built on VMware gives you that foundation, with IT Vortex acting as architect, integrator, and operator rather than a reseller of licenses.
The question is not when your SSL certificate renews. It is whether you could reissue every certificate you own within 24 hours, and how you would know if you missed one.
Bring that question to your next leadership meeting. If the honest answer is uncertain, you have found your project, and it is far cheaper to scope now than during a forced revocation or an expired gateway on a busy Monday.
IT Vortex helps mid-market organizations answer it with an inventory, a plan, and an operating model that holds up as validity periods shrink. Schedule a working session with Lou Corriero, VP Cloud at IT Vortex, to map your certificate exposure across cloud, desktop, backup, and security infrastructure before the next step on the schedule arrives.
