BR Violation Report: Let's Encrypt certificate issued for an unregistered domain *.ph

Hello,

I am writing to report a potential Baseline Requirements violation regarding certificate misissuance. A Let's Encrypt certificate appears to have been issued and remains active for a .ph domain name that is completely unregistered.

Here are some details for example:

Domain Name: ruparupa.ph
Date of Issuance: 6/11/26, 7:03:57 AM GMT+3
ruparupa.ph.pem (1.3 KB)

This one is just an example domain, it also happens for some of the rest of the unregistered .ph domains.

Evidence of Non-Registration:
Because .ph does not utilize a standard, open Port-43 WHOIS server, I have manually checked the domain status directly on the official dotPH registry website (dot.ph). The registry confirms that this domain is currently available for purchase and is completely unregistered.

Because the domain is unregistered, it should not have been possible to pass ACME domain validation (DV) workflows.

Could a Let's Encrypt engineer please review the internal validation logs for this issuance to see how this occurred?

Thank you for your time and for keeping the Web PKI secure.

It looks like the .ph registry returns an A record even for an unregistered domain. Consequently, the operator of the host at that IP address would be able to demonstrate control of the name in question. The BRs do not require that an applicant be a domain's registrant, and indeed they regularly are not (such as in cases where a site delegates TLS termination to a CDN).

Thank you for the clarification — that makes sense. I understand that BR validation is based on demonstrated control of the IP, not registrant status.

That said, I wanted to flag the broader context in case it's useful: the entity that obtained these certificates appears to be ParkLogic, a domain parking provider. They operate a wildcard DNS setup that resolves all unregistered .ph domains to a single IP (45.79.222.138), and appear to have mass-requested SSL certificates for domains that are entirely unregistered.

According to ParkLogic's own website, their system "accurately values each visitor and routes the traffic to the highest paying advertiser" — meaning they are actively monetizing traffic to these unregistered domains over HTTPS. This raises a concern: nothing stops a malicious actor from simply being the highest paying advertiser for a typosquatting domain, obtaining a trusted TLS certificate for it, without ever registering the domain.

I'm not sure if this rises to a BR violation, but it seemed worth surfacing as a potential systemic abuse pattern.

I'd suggest contacting ICANN at ICANN Complaints Office - ICANN to report this potential abuse.

I am not sure this is within ICANN's jurisdiction, as they oversee registrars and registries, not Certificate Authorities or domain parking providers.

The .ph registry is at least operating the wildcard so that would make them partially responsible, I recommended contacting ICANN as this is similar to a prior case (Site Finder - Wikipedia) where Verisign operated a search service on all unregistered domains.

I don't see how your complaint is in the CA (or BR) jurisdiction at all. Having a wildcard on a TLD used like this makes me sad, sure, but users going to the sites have as much right to a private and tamperproof connection as a user going to any other site. And the content of the site might be auctioned off to the highest bidder, sure, but I could do the same on my own site if I wanted to and it wouldn't affect whether I should be able to get a certificate.

First, and foremost, ICANN has no oversight over ccTLDs, the TLDs that are assigned to a sovereign government of the country or territory. ICANN's role is usually limited to establishing line of communication with a registry deemed authorized by the sovereign nation government and delegating a TLD to them.

If the government of the Philippines is fine with abuse of non-registered domains, there is nothing ICANN can do.

The "Site Finder" case was a different one, because it involved .com and .net (gTLDs), for which ICANN has oversight, and did eventually intervene.

The SSAC findings and recommendations in the aftermath of the Site Finder debacle do apply to ccTLDs, but that doesn't mean that ICANN has any ability to enforce those behaviors.

ICANN's Security and Stability Advisory Committee SSAC issued a report (SAC006) on 9 July 2004 on Redirection in the COM and NET Domains. The report recommends that "Synthesized responses should not be introduced into top-level domains (TLDs) or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries over which the operator may have little control or influence.".