Changing from one certificate type to another — DV to OV, or OV to EV — isn't an in-place upgrade of your existing certificate; it means going through the full issuance process again for a new certificate, this time with the additional validation the new type requires.
| Change | New validation needed | Typical time |
| DV → OV | Organization verification | 1–3 business days |
| OV → EV | Full extended validation | Up to a week+ |
| EV → DV | None extra (downgrade) | Minutes |
The process
- Order the new certificate type from your CA, which will trigger the appropriate validation level (organization verification for OV, extended verification for EV) — expect this to take longer than a DV issuance, since it now involves manual review.
- Once issued, install the new certificate, replacing the old one on your server.
- Optionally revoke the old certificate once the new one is confirmed working, though this isn't strictly required if the old one is simply left to expire naturally and isn't otherwise a security concern.
There's no cost or technical benefit to "converting" rather than simply ordering the new type fresh — the validation process itself is the actual work involved, not any technical modification to an existing certificate file.
What to do if you need to change validation tiers mid-validity-period
Changing from DV to OV or EV (or the reverse) generally requires a fresh certificate order at the new validation tier, since the existing certificate's validation level is fixed at issuance — there's no in-place upgrade or downgrade of an already-issued certificate's validation tier.
How to time a validation tier change to avoid any coverage gap
Issuing the new certificate at the desired validation tier before revoking or letting the old one expire, then switching your server's active certificate only once the new one is confirmed correctly installed, avoids any gap in HTTPS coverage during the transition between validation tiers.
What cost and validation time differences to expect when moving to a higher tier
Moving from DV to OV or EV involves both a cost increase (reflecting the more thorough validation) and a longer issuance timeline (days rather than minutes), both worth planning for in advance rather than assuming an upgrade completes as quickly as your original DV issuance did.
How to determine whether your specific compliance or business need actually requires the change
Reviewing the actual specific requirement driving a validation tier change, a stated contractual clause, a specific regulatory requirement, or simply an internal policy preference, clarifies whether the change is actually necessary or based on an assumption worth double-checking before investing the additional cost and time OV or EV validation requires.
Why some organizations maintain both DV and OV certificates for different purposes simultaneously
An organization might run DV certificates broadly across many low-stakes internal or marketing subdomains while reserving OV or EV specifically for customer-facing, transaction-critical domains — a reasonable, cost-conscious approach that applies higher validation only where its specific benefit (compliance, contractual requirement) applies.
What to do if you're unsure which validation tier a compliance requirement really specifies
If a compliance document or partner requirement references SSL certification without specifying an exact validation tier, clarifying with whoever issued the requirement avoids either under-provisioning (risking non-compliance) or over-provisioning (unnecessary cost) based on an incorrect assumption about what's in reality required.
How to handle a validation tier change for a certificate covering multiple domains
Changing validation tier for a multi-domain or wildcard certificate requires the new, higher-validation issuance to cover every domain the original certificate did — confirming your new order's domain list exactly matches what needs continued coverage avoids inadvertently dropping a domain during the tier transition.
A closing note on choosing the right validation tier deliberately rather than by default
Rather than defaulting to whatever validation tier a previous certificate happened to use, periodically reconsidering whether your actual current needs still match that tier, following the guidance covered throughout this guide, ensures you're neither under-provisioned for a genuine requirement nor paying for validation depth you don't need.
Loading comments…