Certificate Renewal and the DCV 200-Day Domain Reuse Policy: What Changes for Renewals

If your domain was validated more than 200 days before your renewal certificate is issued, you must complete domain control validation (DCV) again, even if your current certificate is still valid. 

Since March 15, 2026, CA/Browser Forum rules limit how long a Certificate Authority can reuse a completed DCV to 200 days, down from 398 days. For years, many renewals simply reused last year’s validation and issued in minutes. That is no longer a safe assumption. 

The business risk is simple. A renewal that stalls on an unexpected validation step can leave a site running on an expiring certificate. When it lapses, visitors see browser security warnings, checkout and login pages lose trust, and APIs or integrations that depend on TLS can fail. This guide explains what changed for renewals, how to tell in advance whether your renewal will need fresh validation, and how to renew without interruption. 

What the 200-day DCV reuse policy is and who it affects 

Domain control validation is the check every publicly trusted CA must perform to confirm you control each domain on a certificate. SSL.com supports email, HTTP file, DNS CNAME and DNS TXT methods. Once completed, a DCV can be reused for later issuances for a limited time, called the reuse period. 

CA/Browser Forum Ballot SC-081v3 introduced a phased schedule that shortens both maximum certificate validity and validation data reuse between March 2026 and March 2029. The first step took effect on March 15, 2026: 

Who it affects: anyone renewing or reissuing a publicly trusted SSL/TLS certificate, including DV, OV and EV certificates, wildcards and multi-domain (SAN/UCC) certificates. Private PKI certificates are excluded. 

Who it does not affect: code signing certificates. Their validation requirements are separate and unchanged by this ballot. (CA/B reuse changes) Certificates already issued are also unaffected and stay valid until their stated expiration date. 

These are industry-wide requirements that apply to every publicly trusted CA. SSL.com cannot extend reuse periods or make exceptions. 

How it works: two separate clocks 

Every certificate you renew now runs on two independent deadlines, and both must be tracked. 

• The certificate clock counts down to your certificate’s expiration date. When it runs out, browsers show warnings. 

• The validation clock starts when a DCV is completed and runs for 200 days. When it runs out, SSL.com cannot use that validation to issue another certificate. 

The date that matters is the issuance date of the new certificate, not the date you place the renewal order. If the validation clock has expired by the time SSL.com is ready to issue, a new DCV is required first. 

What this changes for renewals 

• Renewal no longer means “reuse last year’s validation.” A domain validated for last year’s certificate will almost always be outside the 200-day window by renewal time. 

• Every domain is checked individually. On a multi-domain or wildcard certificate, each name must have DCV within 200 days. A wildcard (*.example.com) and its base domain (example.com) each need their own valid DCV. 

• Reissues count too. Rekeying, replacing a compromised key or adding a SAN is a new issuance, so all domains on the certificate, old and new, must meet the 200-day rule. 

• Multi-year plans need periodic revalidation. Multi-year packages are delivered as a series of shorter certificates, and each one needs a DCV inside the window at its issuance. 

• OV and EV have a second, longer clock. Organization details are reusable for 398 days, so many OV/EV renewals need a fresh DCV but not a full organization re-vetting. Once organization validation is older than 398 days, it must be completed again. 

The schedule keeps tightening 

200 days is the first step of a phased reduction. 

By 2029, certificates will need replacing roughly every 47 days and DCV repeating every 10 days, which makes manual renewal impractical for most teams. Habits you build now for the 200-day window, such as tracking validation dates and automating DCV, carry directly into each later phase. 

Will my renewal need fresh validation? 

Use the age of each domain’s most recent DCV on the day the new certificate will be issued. 

 
A single lapsed DCV on a base domain can block several wildcard or SAN issuances at once, so treat base and wildcard validations as high priority.  

How to renew under the 200-day policy 

The renewal workflow itself is unchanged; what changes is checking validation first and leaving time for DCV. These steps combine both. 

Prerequisites 

• Access to your SSL.com account with permission to manage the order. 

• Control of at least one DCV channel for every domain on the certificate: a listed admin email address (admin@, administrator@, webmaster@, hostmaster@ or postmaster@), the ability to publish a file on the web server, or the ability to edit DNS records. 

• A new CSR, ideally generated with a new private key on the server where the certificate will be installed.  

• For OV/EV: current company details in public registries or your D-U-N-S profile, and a publicly listed business phone for the callback. 

Steps 

1. Check each domain’s validation dates. In your SSL.com account, go to Account > Domains and open each domain’s detail view. It shows the date DCV was completed and when it expires. Treat anything expiring within 30 days as urgent. Teams with many domains can monitor this through the SWS API /domain endpoint. 
2. Decide whether you need fresh DCV. If any domain’s DCV will be older than 200 days on the expected issuance date, plan to revalidate it. For OV/EV, also check whether organization validation is older than 398 days. 
3. Start the renewal. Log in, open the Orders tab and click Renew on the certificate’s details page, or use the link in your renewal notice. (Renew Your SSL/TLS Certificate 
4. Choose the term and SANs, then pay. Adjust the duration and, for multi-domain certificates, the number and names of SANs. Any remaining time on your current certificate, up to 30 days, is added to the new one. (Renew Your SSL/TLS Certificate) 
5. Submit your CSR and confirm SANs. Upload the CSR, check every SAN for spelling and add the www subdomain if you need it covered. (Renew Your SSL/TLS Certificate) 
6. Complete DCV for every domain outside the window. Choose a method per domain: 
   • Email: fastest, usually minutes; no technical changes needed. 
   • HTTP file: place the file in /.well-known/pki-validation/ on the domain; works without DNS access. 
   • DNS CNAME or TXT: best for automation, but DNS propagation can take up to 48 hours, so allow a 24–48 hour buffer. 
7. Complete organization re-validation if required (OV/EV). Respond quickly to document requests and keep the authorized contact available for the callback. A temporary DV certificate is available while OV or EV validation completes, so your site stays protected. 
8. Install the new certificate. SSL.com issues the certificate once validation is complete. Install it and confirm the site serves the new certificate before the old one expires. 

If DCV expires mid-renewal: start a new DCV for each affected domain, complete the challenge and continue once validation is confirmed. A new DCV starts a fresh 200-day window, and refreshing DCV while an order is in process does not interrupt it. 

Automate renewals with ACME 

For servers you manage directly, SSL.com’s ACME service handles validation at renewal and schedules issuance before expiry. It integrates with cPanel, Plesk, Kubernetes, Nginx and Apache. Automation turns the two clocks into a background task rather than a calendar reminder, and it is the most reliable way to prepare for the 100-day and 47-day phases. 

Best practices for smooth renewals 

• Track validation like a certificate. Record each domain’s DCV expiry (200 days after completion) and, for OV/EV, organization validation expiry (398 days). Set reminders 30 days ahead.  

• Validate close to issuance, not months ahead. A DCV completed six months before you renew may expire before you use it. Aim for 1–4 weeks before you need the certificate. 

• Start renewals early. SSL.com recommends a lead time of the same day for DV and 5–7 business days for OV/EV. 

• Prioritize base and wildcard domains. One lapsed base-domain DCV can hold up several certificates. 

• Keep business records current (OV/EV). An up-to-date D-U-N-S profile and registry listing speed up organization re-validation. 

• Automate where you can. Use ACME or DNS-based methods your tooling can update, so validation keeps pace as reuse periods shrink. 

Frequently asked questions 

My certificate is still valid. Why do I need to validate again? Certificate validity and DCV reuse are separate. The renewal is a new issuance, and it needs DCV completed within the last 200 days.  

Does this affect certificates I already have? No. Certificates issued before March 15, 2026 remain valid until they expire.  

Do I need to repeat organization validation every renewal? No. OV/EV organization information can be reused for 398 days, so it is repeated roughly once a year.  

Does the 200-day rule apply to code signing certificates? No. It applies only to SSL/TLS certificates. 

Can SSL.com extend my validation period? No. The limits are set by the CA/Browser Forum and apply to every publicly trusted CA.  

Conclusion 

The 200-day DCV reuse policy does not make renewal harder, but it does make validation a planned step instead of an afterthought. Check your domain validation dates before renewal and plan revalidation for any domain approaching the 200-day limit.  

Teams that track both clocks, validate close to issuance and automate where possible renew on time, avoid browser warnings and protect customer trust. SSL.com’s account dashboard, multiple DCV methods, temporary DV coverage for OV/EV orders and ACME automation keep that process simple today and ready for the 100-day and 47-day phases ahead. For help with a specific renewal, contact support@ssl.com.