Key Summary
- Industry trends are pushing SSL certificate maximum validity toward shorter durations, and cases have been confirmed where certificates prepaid for 365 days are actually issued for only 200 days
- In manual installation environments, certificate expiration dates are scattered across sites, so if a CA’s renewal flow is not intuitive at the moment a large-scale reissuance and reinstallation is needed, operators face a high risk of incurring additional costs
- The core UX problem exposed in the Namecheap case is that the rekey (residual-period reissuance) path, which runs separately from the ‘buy a new certificate’ icon, is not clearly communicated to users — and as a result, users fail to reuse the already-paid residual period and end up paying extra
Analysis
Table of Contents
- Key Summary
- Why SSL Certificate Renewal Always Falls Into the Same Trap
- SSL Certificate Renewal Decision Criteria: How to Split by Environment
- 200-Day Issuance Policy Comparison by CA
- Proven Response: Automation + Monitoring
- Practical Application Points
- Practical Application Points
- Common Mistakes
- What to Do Right Now
- What to Do Right Now
- Frequently Asked Questions
- Frequently Asked Questions
- Closing
- Reference Source
SSL certificate renewal schedules for 10 WatchGuard firewalls were set on a yearly cycle. Three months later, four certificates were discovered in the Namecheap dashboard that had gone through as ‘new purchase’ rather than ‘reissue.’ The already-paid residual period was discarded entirely, and the extra cost approached roughly $500. This article, written from an operator’s perspective, outlines how SSL certificate renewal should be designed in environments where non-ACME appliances are mixed in.
Why SSL Certificate Renewal Always Falls Into the Same Trap
Industry trends are moving SSL certificate maximum validity in a shorter direction. Following CA/Browser Forum decisions, there is still room for it to drop to as little as 90 days in the future. The collision with prepaid structures is the problem. When you pay for 365 days but receive a 200-day certificate because of issuance-time policy, the remaining 165 days can only be reused within that same CA.
The UX defect exposed in the Namecheap case is that the rekey (residual-period reissuance) path — which exists separately from the ‘new purchase’ button — is not communicated to users. Operators typically read rekey, renew, and reissue as the same thing because the menu names differ. Each CA defines them differently. This one small difference causes already-paid periods to disappear, and in multi-site environments that cost multiplies.
WatchGuard’s lack of ACME-based auto-renewal support has been one of users’ long-standing requests. As of 2026, it still has not been reflected in the vendor’s roadmap. In field deployments where certificates must be manually distributed across multiple remote WatchGuard appliances, this limitation is the single biggest friction point. Operator reports on the 200-day certificate transition at one point drew more than 100 comments on r/sysadmin.
SSL Certificate Renewal Decision Criteria: How to Split by Environment
There are two variables to look at first when deciding on a process: ① whether ACME is supported, and ② the number of sites. In reality, SSL certificate renewal itself is not the goal — preventing service outages from certificate expiration is what matters.
If you have five or more appliances that do not support ACME (many WatchGuard models, legacy load balancers, industrial control devices), the process is effectively manual. In that case, paying upfront for multiple years and reissuing in installments is the cost-advantaged approach. Paying for a 3-year certificate up front and then reissuing one year at a time reduces the per-unit residual-period loss.
If your stack is dominated by ACME-capable servers such as nginx, Apache, Caddy, or Traefik, you can automate issuance and deployment with a client like certbot. Even when 90-day certificates are issued automatically, however, monitoring alerts need to start 60 days before expiration — not 30 — so you have time to respond to a failed reissuance.
200-Day Issuance Policy Comparison by CA
When you pay for 365 days, the actual issued certificate lifetime and the way residual periods are handled differ by CA. From an operator’s perspective, the most visible difference is the transparency of the guidance flow.
| CA | Actual Issued Lifetime | Residual Period Handling | Reissuance UX Guidance |
|---|---|---|---|
| Namecheap (Comodo) | 200 days | Residual carries over on rekey | Separated from new purchase; guidance is weak |
| Sectigo (direct purchase) | 200 days | Residual carries over on rekey | Rekey menu is clearly labeled |
| DigiCert | 200 days | Varies by renewal timing | Rekey vs. renew clearly distinguished |
| GoDaddy | 200 days | Partial carryover on reissuance | Korean-language guidance pages provided |
| Let’s Encrypt | 90 days | N/A (free) | Assumes ACME automation |
This table synthesizes CA official documentation with operator reports. Even at the same 200 days, Namecheap and DigiCert handle residual-period carryover differently and present it differently. The first thing to do when setting up an SSL certificate renewal process is to check directly how visible the rekey menu of your current CA is on the payment screen.
Proven Response: Automation + Monitoring
There are four workarounds frequently discussed in the community: ① operating an ACME-compatible internal CA (smallstep, step-ca); ② issuing with certbot and writing deployment scripts; ③ paying upfront for multiple years and reissuing in installments; ④ setting up pre-expiration alerts with zabbix or checkmk.
The combination I have found most effective in the field is ③ + ④. Paying for a 5-year certificate up front and reissuing it in yearly installments produces almost no extra cost. Add to that the checkmk ssl-cert-check rule with four-stage alerts at 60, 30, 7, and 1 day(s) before expiration, and the chance of an operator missing a fragmented expiration date drops significantly.
Operating an internal CA is only meaningful in environments where external CAs are not allowed by security policy. Because it brings browser trust-chain issues, it cannot be applied to general SaaS or external services. certbot-based automation is only effective for ACME-capable appliances. A workaround of placing an nginx reverse proxy in front of WatchGuard does exist, but it raises configuration complexity by a corresponding degree.
Practical Application Points
Practical Application Points
- First, determine the share of appliances that do not support ACME. If it is 30% or more, paying upfront for multiple years plus installment reissuance is the cost-advantaged approach.
- When paying upfront for multiple years, confirm the residual-period carryover conditions in writing through the CA’s sales channel. Menu structure and policy can change at any time depending on the CA’s circumstances.
- Separate certificate replacement work into a nighttime window and spread schedules across sites. WatchGuard reboots are long, so simultaneous work across multiple sites increases operator fatigue.
- Document the configuration differences between wildcard and SAN in a single place. The number-one cause of reissuance rejection is missing SAN entries.
- Clean up old certificates immediately after installing the new one. If the intermediate (chain) certificate has changed, a chain error will occur.
Common Mistakes
The most common case is starting the reissuance only right before expiration. Even though issuing a certificate takes just 10 minutes, reinstallation, reboot, and chain verification take 30 minutes to an hour. For appliances like WatchGuard that require a reboot, it takes even longer. Starting 7 days before expiration is effectively already too late.
The next most common mistake is reading rekey/renew/reissue as the same thing. In Namecheap, renew updates an existing certificate under the same conditions, while rekey reissues it by carrying over the residual period. The two menu options have different prices and different outcomes. When an operator confuses the two, an already-paid period disappears.
Cases are also frequent where SAN entries are missed when reissuing a wildcard certificate. If the original certificate had three SAN entries and the reissuance includes only two, one of the domains will immediately throw a certificate error. Always compare the SAN list before issuing a new certificate.
The fourth is the chain error that occurs when old certificates are not cleaned up after the new one is installed. If the intermediate (chain) certificate has changed but the old chain remains, browsers will display an ‘untrusted issuer’ error. This problem is particularly pronounced on non-ACME appliances.
What to Do Right Now
What to Do Right Now
- Build a table organizing the SSL certificate expiration dates currently in operation by domain. If even one certificate expires within 30 days, start the reissuance immediately.
- Capture the location of the rekey menu in your current CA and pin it to the team wiki. Add a note explaining how it differs from the ‘new purchase’ button.
- Reconfigure expiration alerts to four stages: 60/30/7/1 day(s). Check the zabbix tls.expires trigger or the checkmk ssl-cert-check rule.
- Rewrite the list of non-ACME appliances. If the share is 30% or more, contact your CA about paying upfront for 3 years plus installment reissuance.
- Pick the most recent reissuance rejection, and classify its cause: missing SAN, CSR error, or domain validation failure. Check whether the same cause keeps repeating.
Frequently Asked Questions
Frequently Asked Questions
When I receive a 200-day certificate, what happens to the remaining 165 days?
It depends on the CA, but if you reissue through the rekey menu, the residual period of the existing certificate is carried over to the new one. On the other hand, if you go through with a ‘new purchase,’ the residual period disappears and the 200 days restart from zero. It is also worth remembering that carryover is only possible within the same CA.
Is there any way to work around ACME auto-renewal on WatchGuard appliances?
The appliance itself has no ACME, but you can place nginx or Caddy as a reverse proxy in front of it, have certbot automatically issue and renew the certificate, and then deploy a private certificate to the WatchGuard. This does require a change to the network configuration, however, and a review of trust with external clients should come first.
If I run an internal (Private) CA, can I save the cost of an external CA?
There is a cost-saving effect. However, because it is not registered in the browser trust chain, it cannot be used for services exposed to external users. It is meaningful only in closed environments such as internal portals, API gateways, and IoT device authentication. It is often used in parallel with free external CAs such as Let’s Encrypt.
Isn’t a 30-day-before-expiration alert enough?
For a single-domain environment, it is sufficient. However, in multi-site setups where 10 or more certificates may expire at the same time, completing all reissuance and reinstallation within 30 days is difficult. For appliances like WatchGuard that require a reboot, alerts need to start coming in 60 days before expiration to be safe. Spreading out the SSL certificate renewal schedule also reduces the risk of multiple expirations clustering at the same time.
Closing
The shift to 200-day certificates demands a change in operations, not just a shorter cycle. If you treat SSL certificate renewal as a once-a-year task to be done all at once, costs will keep spiking and expiration incidents will keep recurring. If you use installment reissuance and a multi-stage alert system as your baseline, operational burden will barely grow even as certificate lifetimes get shorter. The higher the share of non-ACME appliances like WatchGuard, the greater the benefit of paying upfront for multiple years. The most realistic workarounds for certificate fragmentation ultimately boil down to two things: distributing issuance and making expirations visible.
Reference Source
This article was written after checking the following original source: r/sysadmin — What is your SSL certificate provider doing now that 200 day certs are starting to expire? My provider (Namecheap) is being sketchy.
Expert Commentary (AI)
Security Systems Operations Specialist
In the era of shortened certificate lifetimes, the ‘non-automatable zone’ becomes the new single point of failure
The CA/B Forum’s lifetime-shortening roadmap is best read as targeting 47 days around 2029, with 200 days as the midpoint, and this is effectively a declaration of the end of the once-a-year manual renewal model. ACME is already the industry standard for issuance automation, but firewall appliances, legacy load balancers, and industrial devices are left out of this trend, and in multi-site operations that zone is the bottleneck that creates most of the expiration incidents. Paying upfront for multiple years and then reissuing in installments is a reasonable choice for near-term cost control and distributing expiration dates, but once lifetimes drop to 90 days or below, the economics of the upfront-payment model itself and the management burden will inevitably be restructured. Multi-stage monitoring at 60/30/7/1 day(s) before expiration is a basic practice, but alerts alone are not enough; the next step is designing a pipeline that connects issuance to deployment, reboot, and chain verification. A workaround based on a reverse proxy in front is an improvisation that works in practice, but if the proxy becomes a new failure point and attack surface, it is dangerous to introduce it without availability and security review. The fundamental solution is not operator-side workarounds but ACME adoption by appliance vendors, and making ACME support a written requirement at the procurement stage is the most cost-effective pressure tool.
PKI Infrastructure Specialist
The absence of standards for the terms rekey, renew, and reissue, and residual-period handling in the upfront-payment model, are the real cracks in this transition
After the CA/B Forum banned multi-year certificate issuance, the ‘prepay + reissue’ structure became an industry compromise, and the fact that residual-period carryover policies differ for each CA is not a bug but the inevitable consequence of this model. The Baseline Requirements only enforce the upper limit on issuance lifetime; the proprietary terminology and carryover rules used by resellers are not subject to standardization, so user confusion remains an area for improvement but the institutional drive to enforce it is weak. The shorter lifetimes get — from 200 days to 100 days to 47 days — the weaker the value proposition of upfront-payment commercial CAs becomes, and there is a high probability that the certificate market will be restructured around ACME-based free issuance and CLM platforms. The security rationale for shorter lifetimes (reducing key-compromise exposure time and minimizing the impact of misissuance) is correct in direction, but it is only persuasive when premised on outdated key-storage practices, and in environments where hardware key protection and automated rotation are already widespread, its marginal utility drops sharply. The realistic corporate response is not CA-by-CA UX comparison but the introduction of CLM tools, issuance automation, and the bifurcation of closed segments into private CAs and trust management. That said, appliances and closed-network segments will be the last to benefit from this restructuring, so vendor adoption of ACME will remain the biggest challenge for the PKI ecosystem over the next five years.
Critical Analyst
The winners of shorter certificate lifetimes are decided in advance — those who control the automation infrastructure
The surface-level narrative says ‘shorter lifetimes are safer,’ but if you look behind the scenes, the biggest beneficiaries of this change are the large CAs and the cloud and automation ecosystems that already have ACME and CLM infrastructure, while the biggest cost bearers are the small and mid-sized operators who relied on manual renewals. The answer to ‘why now, specifically’ is closer to market than to technology: as lifetimes get shorter, the number of issuance and reissuance cycles multiplies, which structurally favors players with the economies of scale in automation in the per-unit pricing competition. If appliance vendors have not reflected ACME in their roadmaps despite years of user requests accumulated on public forums, that is better read not as a technical delay but as the result of an incentive structure in which renewal friction feeds into maintenance contracts and professional service revenue. The fact that the rekey path is hidden behind the new-purchase button in reseller consoles is also more likely the product of a structure in which the new-purchase conversion rate of renewal-inflow customers is tied to revenue metrics, creating an incentive against clear residual-period carryover guidance, rather than a pure UX defect. One cannot say the security logic itself is wrong, but the fact that cost and risk are asymmetrically passed on depending on automation capability is not officially addressed anywhere. The question we should really be paying attention to is not ‘why are lifetimes getting shorter’ but ‘through this transition, who is gaining market share and who is paying the cost.’
- There is a high probability that the lifetime-shortening schedule was passed through a CA/B Forum voting structure in which browser vendors and large CAs hold significant influence, and it may function as a restructuring device that accelerates the market exit of small CAs and resellers without automation infrastructure — the distribution of voting interests is circumstantial evidence of this.
- The fact that the rekey option in reseller consoles is separated from the new-purchase button and given weak guidance is more likely not a coincidental UI error but the result of a revenue structure that drives new-purchase conversions of renewal customers, which works against clear residual-period carryover guidance — a recurring pattern in which no company places residual-period carryover guidance on the front page supports this.
- The long-running lack of ACME support from firewall vendors is more likely tied to an interplay of interests in which certificate renewal friction drives up annual maintenance contract renewal rates and professional service demand than a technical delay — the fact that user requests have accumulated over years while roadmap gaps persist is circumstantial evidence.
Leave a Reply