Skip to content

The .ph Certificate Mystery: When Thousands of HTTPS Certificates Disappeared

An unusual shift in certificate issuance revealed how DNS wildcarding and automated HTTPS can create an enormous amount of misleading security telemetry.

While reviewing the Top-Level Domain (TLD) rankings on NOB.center's public Certificate Transparency dashboard, we noticed an unexpected change.

For some time, .ph—the country-code TLD for the Philippines—had consistently appeared among the ten busiest TLDs in our view of newly observed TLS certificates. Then, around August and September 2026, it fell sharply. By October, it no longer appeared among the top twenty.

That was unusual. TLS certificate issuance is a global, high-volume activity. A TLD does not ordinarily fall that far in the rankings without a meaningful change in the infrastructure generating those certificates.

Had Philippine websites stopped using HTTPS? Had a certificate authority changed its policies? Or had something been inflating .ph issuance in the first place?

Our investigation led to a much more interesting explanation: certificates were being issued for domain names that were not even registered.

Executive summary

  • The signal: NOB.center's TLD issuance rankings showed .ph falling from the top ten to outside the top twenty within roughly one to two months.
  • The mechanism: Public reporting documented .ph DNS behaviour that directed otherwise unregistered names to a domain-parking service, enabling automated HTTPS certificate validation.
  • Independent corroboration: A separate CT-monitoring dataset recorded a collapse in .ph-family lookalike names in September 2026, from thousands per week to fewer than 200.
  • The lesson: A publicly trusted certificate confirms a form of domain control during validation. It does not prove the domain was registered, that the website is legitimate, or that the certificate represents a newly deployed business service.

What Certificate Transparency actually tells us

Every publicly trusted TLS certificate must be recorded in public Certificate Transparency (CT) logs under the policies enforced by major browsers. These append-only records make certificate issuance observable to domain owners, researchers, and security teams.

That visibility is useful. An unexpected certificate for login.example.com could indicate a forgotten deployment, a third-party service, or unauthorized control of part of a company's infrastructure. A newly certified lookalike such as example-support-login.net may warrant investigation for brand impersonation or phishing.

NOB.center processes public CT activity to identify certificate issuance patterns and, for organizations using the platform, to surface certificates matching protected domains and potential lookalike domains.

But CT has an important limitation: it tells us a certificate was issued—not why it was issued, whether the associated domain is registered, or what the website actually does.

The .ph anomaly is a particularly striking illustration of that distinction.

The anomaly: a top-ten TLD falls out of view

The initial observation came from the TLD movement statistics in our public CT telemetry dashboard. .ph had been a surprisingly prominent source of certificates compared with many larger and more widely used domain extensions.

Then the volume seemingly evaporated.

The NOB.center observation is a ranking change, not a published historical count of all .ph issuances. However, independent research offers a more quantitative view of closely related activity.

In an October 2026 analysis, the security monitoring service Greyphish documented unusually large numbers of .ph, .com.ph, .net.ph, and .org.ph lookalike hostnames in CT data. Its sample tracked names resembling public brands, rather than the entire TLD, so the counts below should not be interpreted as total .ph certificate issuance.

Week beginning .ph-family lookalike names observed
July 6, 2026 5,662
July 20, 2026 17,047
August 10, 2026 9,978
August 24, 2026 6,889
September 7, 2026 1,061
September 14, 2026 36
September 21, 2026 126

Source: Greyphish, “Monitoring Certificate Transparency logs for phishing domains”, published October 1 and updated October 3, 2026. Figures describe its selected public-brand lookalike dataset, not all certificates issued under .ph.

The resemblance to the shift we observed was hard to ignore. Both showed substantial .ph-related certificate activity followed by a steep decline around September.

Correlation is not attribution

These datasets use different collection methods and measure different populations. Their timing supports a shared explanation, but the published figures alone do not prove that one operator caused every certificate represented in NOB.center's TLD rankings.

The unexpected connection: domain parking and wildcard DNS

To understand the likely cause, we need to look beneath the certificate layer—at DNS.

Ordinarily, if someone requests an entirely unregistered domain, DNS responds with NXDOMAIN: the name does not exist. No web server is reached, and there is no obvious endpoint able to demonstrate control of that name for certificate issuance.

A registry can behave differently. With wildcard or synthesized DNS responses, queries for otherwise nonexistent names can resolve to an IP address chosen by the registry or its infrastructure partner.

In June 2026, a public discussion on the Let's Encrypt community forum documented exactly this kind of behaviour under .ph.

The report described ruparupa.ph, a domain that appeared available for registration while nevertheless having a valid Let's Encrypt certificate. The discussion attributed the catch-all response to infrastructure associated with ParkLogic, a domain-parking provider, and identified the address 45.79.222.138.

The surprising part is that this does not necessarily indicate a failure of the certificate authority's validation rules.

How can a certificate be issued for an unregistered domain?

The answer lies in what Domain Validation (DV) certificates actually verify. A CA must establish that the applicant controls the requested domain under an approved validation method. That does not always require the applicant to be the registered domain holder. For example, businesses routinely delegate HTTPS hosting to CDNs that handle certificate issuance on their behalf.

With a registry-level DNS catch-all, the same principle can extend to names that nobody has registered.

flowchart TD
    A[Request for an unregistered .ph hostname] --> B[.ph DNS infrastructure]
    B --> C[Catch-all DNS response]
    C --> D[Domain-parking HTTPS server]
    D --> E[Automated certificate request]
    E --> F[CA domain validation]
    F --> G[Public TLS certificate]
    G --> H[Certificate Transparency logs]
    H --> I[CT monitoring and analytics]

This diagram illustrates a technically plausible workflow supported by the public findings. The precise trigger and implementation of ParkLogic's certificate automation have not been publicly established.

  1. A client attempts to visit a hostname such as brand-account-check.example.ph (illustrative, not a real observed certificate).
  2. Rather than reporting the unregistered name as nonexistent, DNS provides an address for a catch-all service.
  3. The service receives traffic for that hostname and can initiate or reuse an automated certificate issuance workflow.
  4. During an ACME HTTP-01 challenge, the CA resolves the hostname and requests a specific token under /.well-known/acme-challenge/.
  5. If the service controls the destination and serves the expected token, the validation can succeed, subject to the CA's other required checks.
  6. The resulting certificate or precertificate appears in CT logs, even though the hostname need not correspond to an individually registered domain.

Important: Simply visiting a hostname does not automatically create a certificate. That depends on server-side automation. The existence of the catch-all DNS alone does not prove how or when each certificate request was triggered.

This creates a potentially large amplification effect. A stream of unrelated probes, misspellings, automated requests, or other traffic could lead to certificate issuance for many distinct names if the hosting service is configured to request certificates on demand.

For a CT analytics system, those names can look like thousands of new websites. For a brand-monitoring system, they can resemble a coordinated typosquatting campaign.

Neither interpretation is necessarily correct.

Did something change in September?

The timing strongly suggests that a high-volume issuance pattern diminished or stopped, but we have not verified the specific operational event responsible.

Several possibilities fit the evidence:

  • A domain-parking operator may have disabled or restricted on-demand certificate issuance.
  • Automation could have been changed to issue certificates only for a narrower set of names.
  • The traffic or scanning activity that triggered issuance may have declined.
  • An upstream service or policy change could have reduced the number of successful requests.

The public evidence does not establish which of these occurred. In particular, a decline in issued certificates does not by itself prove that the underlying wildcard DNS behaviour was removed.

What we can say is that a public June 25 discussion had already raised questions about the practice, and the independently reported CT counts fell sharply several weeks later. This timeline is suggestive, not proof of causation.

Is this a security vulnerability?

Not automatically. A certificate issued through an approved domain-control validation method is not necessarily misissued simply because the hostname is unregistered. Nor does the presence of a brand name in a certificate establish phishing or malicious intent.

But the behaviour does create genuine security and operational concerns.

First, it complicates threat detection. Security teams may spend time investigating certificates for lookalike domains that nobody registered and that may never have hosted a phishing page. Large numbers of such results can hide the events that deserve immediate attention.

Second, it demonstrates why the browser padlock is not an identity check. TLS protects the connection and ties a certificate to validated control of a hostname. It does not verify that the website represents the company its name resembles.

Third, it highlights a DNS design trade-off. Synthesizing successful DNS responses for nonexistent names alters the assumptions made by users and automated systems. ICANN's Security and Stability Advisory Committee has previously advised against synthesized responses at the TLD level, partly because they create unexpected name-resolution behaviour.

A security signal is not a security verdict

An unexpected certificate is a reason to investigate—not, on its own, proof of compromise, phishing, or certificate-authority misconduct. Effective monitoring correlates independent signals before escalating a finding.

What this means for organizations

For a COO or security leader, the business consequence is straightforward: more alerts do not necessarily mean better protection.

A security monitoring product that reports every suspicious-looking certificate without context can overwhelm an analyst or a small IT team. At the same time, ignoring CT activity altogether risks missing genuinely unauthorized certificates or newly emerging impersonation attempts.

A useful investigation asks several separate questions:

  1. Was a certificate issued? CT monitoring establishes the public issuance event.
  2. Is the domain actually registered? RDAP or registry information can help distinguish real registrations from DNS catch-all behaviour, although registry coverage and data quality vary.
  3. Where does the name resolve? DNS context helps identify shared parking or hosting infrastructure.
  4. Is there a meaningful threat to our organization? Brand similarity, infrastructure, deployed services, and subsequent changes help determine priority.
  5. Do we need to act? A newly discovered certificate, an unexpected DNS change, and an altered registration record have different implications and response paths.

This is precisely why correlating data sources matters more than simply collecting them.

From raw CT data to actionable intelligence with NOB.center

The .ph mystery began with a simple observation in NOB.center's live CT statistics: a familiar TLD had abruptly dropped out of the rankings. A change that would have been easy to overlook became a reason to investigate the infrastructure and assumptions behind the numbers.

The same principle applies to protecting an organization's own domains.

NOB.center combines several views of the external domain trust surface:

  • Certificate Transparency Monitoring: Detect new certificates for your domains, examine issuer and certificate metadata, and check certificate-authority authorization records.
  • Typosquatting Detection: Identify candidate lookalike domains appearing in CT logs, including spelling changes, affixes, and TLD substitutions.
  • DNS Monitoring: Track changes to DNS records that can influence where traffic goes and who can validate certificate requests.
  • RDAP / WHOIS Monitoring: Follow changes in registration metadata for domains under your monitoring coverage.
  • Certificate Deployment Monitoring: Verify what TLS endpoints actually serve, rather than relying solely on what has been issued.

The platform also provides customizable alert conditions using the Common Expression Language (CEL). Instead of treating every CT observation equally, organizations can tailor alerting to the issuers, domains, and behaviours that matter to their operations.

That distinction matters: seeing a certificate is the beginning of an investigation. Understanding whether it is relevant is what makes the intelligence useful.

Explore the live data

See how certificate issuance patterns, TLD activity, issuer distribution, and naming signals evolve in the NOB.center Public CT Stats dashboard.

To monitor your organization's own internet trust surface, explore NOB.center or follow the quick-start guide.

The bigger lesson

The .ph case is a reminder that internet telemetry measures systems—not intentions.

An unexpected rise in certificates does not necessarily mean more websites are being deployed. A sudden fall does not necessarily mean businesses have stopped securing their services. Sometimes, a single infrastructure design choice can distort an entire category of data.

What matters is noticing the anomaly, understanding the mechanism, and separating meaningful risk from noise.

That's the difference between collecting security events and turning them into intelligence.

References and further reading

  1. Let's Encrypt Community (June 25, 2026) — BR Violation Report: Let's Encrypt certificate issued for an unregistered domain *.ph. Primary public discussion of the unregistered .ph domain, catch-all DNS, and DV requirements.
  2. Greyphish / Sima Technologies (October 1–3, 2026) — Monitoring Certificate Transparency logs for phishing domains. Independent CT dataset showing the volume and September collapse of .ph-family lookalike names.
  3. NOB.center — Public Certificate Transparency telemetry. Live issuance statistics, including TLD movement and issuer activity.
  4. NOB.center documentation — Certificate Transparency Monitoring and Typosquatting Detection. Platform capabilities and monitoring methods.

Research note: The NOB.center-specific historical finding described here is the observed change in TLD rank supplied by our monitoring review. The independently published counts are attributed to Greyphish. No private ParkLogic operational details or confirmed reason for the September change are claimed.