The archive behind your OV certificate was open for almost seventeen months
You got an OV certificate. Somebody at your company filled in a form, answered a phone call, maybe uploaded a scan of their driver's license, and three days later a certificate arrived. You installed it. You forgot about the paperwork. DigiCert didn't.
On February 4, 2025, DigiCert moved an internal business system out of a VPN-restricted network segment during an infrastructure migration. The new location was reachable from the internet. The system ran an account manager that still offered a self-registration flow meant for other products. Accounts created that way skipped multi-factor authentication. They had no application assigned, so they were supposed to see nothing. They could read the archive.
That's the core of Bugzilla 2084460, opened on October 21, 2026, with a full incident report following on November 1. The exposure ran until July 2, 2026. Someone outside DigiCert read archived customer records between June 27 and July 2. The Register picked it up on November 6; the Hacker News thread barely registered it. That's a mistake. If you buy anything other than DV, this one is about you.
What was in it, and what DigiCert still won't say
According to the full report, most of the accessed data was business contact information: names, business email addresses, phone numbers and business addresses. For "a small minority of customer accounts" it also included "a customer-provided document such as a driver's license, passport, utility bill, or other document with name and address."
DigiCert is firm that certificate operations were untouched. CertCentral and DigiCert ONE were unaffected, no certificates were issued, modified or revoked, and the account "could not write records, act as a validation approver, or issue certificates." The logs back that up, as far as anyone outside can tell. Your certificates are fine. Nobody needs to rotate anything.
The part DigiCert won't pin down is what this archive actually is. The preliminary report described it as a system "that stores information customer representatives provide to us to validate their identity." Two commenters on the bug then asked directly whether the exposed data came from subscriber validation, and how many records were involved. DigiCert's answer, given twice: the information "may be provided during the set up of DigiCert services, authorizations, and other interactions." No number. Root program representatives can get summary statistics on request. You can't.
Two other details from the timeline should bother anyone who runs infrastructure. DigiCert's own staff spotted the foreign accounts on June 18 and concluded they had no data access because no application was assigned. That conclusion was wrong. The actual data access started nine days later. And the "Where we got lucky" field of the report reads "N/A". I'd have filled that one in.
October had three of these
DigiCert's report lists two related incidents from the same weeks, and they're worth reading together.
TWCA (bug 2086949) found unauthorized access to its Registration Authority server on October 27. A legacy RA service that was scheduled to be decommissioned on May 29 was still running. An attacker came in through a vulnerability in a third-party component, found database credentials in an old config backup, and queried table structures, privileges and row counts. TWCA says the audit logs show no modification or export, and it suspended issuance for about 4 hours and 52 minutes as a precaution.
D-Trust (bug 2085547) has the opposite problem. E.ON SE, a delegated enterprise RA, lost subscriber identity-validation records for S/MIME certificates issued between 2015 and 2022 during a migration that ended January 31, 2026. A total of 323,305 log entries are gone. The report doesn't suggest anyone stole them. They just aren't there any more, and the CPS says they must be.
So that's one CA whose archive leaked. TWCA kept an RA service alive months past its own shutdown date, and at D-Trust's RA the records simply vanished. Issuance wasn't touched in any of them. What they share is the identity data you hand over to get a certificate with your company's name in it.
Your documents outlive your certificate
You probably think of validation paperwork as a hoop you jump through once. The Baseline Requirements call it a record, and records get archived.
Section 5.5.1 of the TLS Baseline Requirements requires the CA to archive "documentation related to their verification, issuance, and revocation of certificate requests and Certificates." Section 5.5.2 says it must keep that documentation for at least two years after the later of two events: the last time it was relied on, or the expiry of the last certificate that relied on it.
Now add section 4.2.1. Since March 15, 2026, a CA may reuse validated organization data for up to 398 days. Certificates issued now can live 200 days. Do the arithmetic on a scan submitted today: up to 398 days of reuse, plus up to 200 days of certificate validity, plus two years of retention. That is about three and a half years, and it's the floor. D-Trust's E.ON CPS asks for seven years after expiry. The BRs explicitly let a CA keep records longer than the minimum.
So you can't fix this by asking for deletion. The CA is required to keep it. The only real control you have is what you send in the first place.
Find out which of your certificates needed paperwork
Every publicly trusted TLS certificate carries a CA/Browser Forum policy OID that says how it was validated: 2.23.140.1.2.1 for DV, 2.23.140.1.2.2 for OV, 2.23.140.1.2.3 for IV and 2.23.140.1.1 for EV. Anything other than DV means a human handed identity data to a CA at some point.
This script reads the certificate each host actually serves and prints the level, the issuer and the organization name in the subject:
#!/usr/bin/env bash
# Usage: ./cert-level.sh host1 host2 ...
for HOST in "$@"; do
PEM=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
| openssl x509 2>/dev/null) || { echo "$HOST: no certificate"; continue; }
POLICIES=$(printf '%s\n' "$PEM" | openssl x509 -noout -ext certificatePolicies 2>/dev/null)
case "$POLICIES" in
*2.23.140.1.1*) LEVEL="EV" ;;
*2.23.140.1.2.2*) LEVEL="OV" ;;
*2.23.140.1.2.3*) LEVEL="IV" ;;
*2.23.140.1.2.1*) LEVEL="DV" ;;
*) LEVEL="unknown" ;;
esac
ISSUER=$(printf '%s\n' "$PEM" | openssl x509 -noout -issuer -nameopt multiline \
| awk -F' = ' '/organizationName/{print $2; exit}')
ORG=$(printf '%s\n' "$PEM" | openssl x509 -noout -subject -nameopt multiline \
| awk -F' = ' '/organizationName/{print $2; exit}')
printf '%-28s %-8s %-28s %s\n' "$HOST" "$LEVEL" "${ISSUER:--}" "${ORG:--}"
done
Run against a few public sites it prints something like this:
letsencrypt.org DV Let's Encrypt -
www.paypal.com EV DigiCert Inc PayPal, Inc.
github.com DV Sectigo Limited -
It needs OpenSSL 1.1.1 or later for -ext. EV is matched first on purpose, because some EV certificates assert more than one policy. Feed it your whole host list. The five hostnames you remember off the top of your head won't cut it. If you don't have a whole host list, you probably don't know how many certificates you have. For every OV or EV line, find out who placed the order and what they uploaded. Your CA portal usually shows the organization validation record and the named contacts.
Most OV certificates exist out of habit
My opinion, and plenty of CA sales reps will hate it: most OV certificates in production were bought because someone bought one in 2014 and procurement renewed the line item.
Browsers stopped showing EV in the address bar in 2019. They never showed OV differently from DV. Your users can't tell. Your API clients don't care. What the extra validation actually buys you is a manual renewal path and a slower replacement when the next mass revocation hits. As of this month you can add a stack of identity documents sitting in someone else's archive for years.
There are real reasons to keep OV or EV. Some contracts, regulators and payment schemes demand it. Some internal policies were written by people who will not be talked out of it. Fine. Then make sure a named person owns that decision and can tell you why it's still needed. Everything else should be DV over ACME. If you need a commercial CA, DigiCert and Sectigo both do ACME. If the warranty is why you're paying, read that one first.
The contact list is the part that leaked
Everyone will fixate on the passport scans. I'd worry more about the contact list.
Whoever reads that archive now knows which named people at which companies deal with certificates, plus their direct phone numbers and email addresses. That's a ready-made target list for "your certificate validation has expired, please re-verify here" phishing. The person who receives that email is exactly the person who would believe it.
Three things to do this week:
- Tell the people on your CA account that targeted certificate phishing is likely, and that no CA will ever ask them to log in through an emailed link to keep a certificate valid.
- Use the authorized requester list. Section 3.2.5 of the BRs requires every CA to let you specify, in writing, which individuals may request certificates, and the CA "SHALL NOT accept any certificate requests that are outside this specification." Most companies never set it up.
- Tighten CAA so a stolen identity at one CA doesn't buy issuance. Pin your CAA record to one account where your CA supports
accounturi, and watch Certificate Transparency for anything issued that you didn't order.
dig +short CAA example.com
# example output:
# 0 issue "digicert.com; accounturi=https://..."
# 0 iodef "mailto:security@example.com"
Send less next time
The BRs ask for less than many CAs request. For an organization, section 3.2.2.1 lets the CA verify identity and address through a government agency, a regularly updated third-party database, a site visit or an attestation letter. A utility bill is allowed for the address only, not the identity. A government photo ID is required by section 3.2.3, but that section applies when the applicant is a natural person.
So if your CA asked a colleague for a passport scan to issue an OV certificate for your company, ask which requirement it satisfied. It may be the CA's own CPS, which is allowed to ask for more than the BRs. It may also be convenience. Ask whether a registry lookup or a signed attestation letter from your accountant or lawyer would do instead. Tie the validation to a role mailbox and a company phone number. One employee's private details have no business in there. And ask your CA in writing how long it retains validation documents and where. After this October, it's a fair question.
Frequently asked questions
Do I need to replace my DigiCert certificates because of this incident? No. DigiCert's incident report states that no certificates were issued, modified or revoked, and that the unauthorized account could not approve validations or issue certificates. Your keys and certificates are unaffected; the exposure is the personal and contact data stored in the archive.
How do I find out whether my own documents were among the accessed records? DigiCert says it contacted the affected customers directly with information specific to them and reported the incident to law enforcement. If you hold OV or EV certificates with DigiCert and heard nothing, ask your account contact in writing whether records linked to your organization were in the accessed subset.
Can I ask a CA to delete the documents I submitted for validation? You can ask, but the TLS Baseline Requirements oblige the CA to keep validation documentation for at least two years after it was last relied on or after the last certificate depending on it expired, whichever is later. Deletion before that point would put the CA out of compliance, so expect a refusal until the retention period has passed.
Does a DV certificate from a commercial CA avoid this exposure? Mostly. A DV certificate proves control of the domain and needs no organization documents, so there is no identity file in the archive, but the CA still stores your account contacts and billing details. That is much less than a passport scan and far less useful to someone planning a targeted phishing campaign.
