DNS Hijacks Can Mint Valid TLS Certificates: Harden Origin Trust

A valid TLS certificate answers a narrower question than many systems assume: did a trusted certificate authority issue a certificate for this name under its validation rules? It does not independently prove that the current DNS operator, network endpoint, or service instance is the one your organization authorized.

That gap became visible this week after attackers compromised parts of the .gh, .sl, and .as country-code top-level domain infrastructure. According to Google's Chrome incident response, the attackers changed authoritative DNS records and obtained unauthorized HTTPS certificates for Google and other organizations. Google said its systems were not compromised and it had no reason to believe the issuing certificate authorities had acted incorrectly.

The story reached Hacker News because it challenges a comfortable shortcut: “the certificate validates, therefore the endpoint is ours.” API gateway teams should replace that shortcut with an explicit origin trust model.

Key Takeaways

• Public PKI validation proves certificate-chain and hostname conditions, not organizational authorization by itself.
• Disabling upstream certificate verification is unsafe; enabling it is necessary but may not detect a DNS attacker who obtained a publicly trusted certificate.
• Private trust anchors, tightly scoped server certificates, and mTLS can narrow origin trust when operated correctly.
• Certificate Transparency monitoring and revocation accelerate detection and response; they do not prevent the first unauthorized issuance.
• Restrictive CAA helps constrain issuance but cannot stop an attacker who controls authoritative DNS during the compromise.
• Pin gateway behavior to the deployed release: Apache APISIX 3.19.0 changed effective HTTPS/gRPC upstream verification behavior.

See the Two Independent Control Planes

TLS authentication depends on more than the handshake:

flowchart LR
    G[API gateway] -->|resolve name| DNS[Authoritative DNS]
    G -->|connect to returned address| O[Origin endpoint]
    O -->|certificate chain and name| G
    CT[CT monitoring] -. detects issuance .-> R[Incident response]

DNS tells the gateway where to connect. TLS tells it whether the presented certificate satisfies the configured trust and name checks. If an attacker controls authoritative DNS and can complete domain-control validation, the attacker may obtain a certificate that passes ordinary public-root and hostname validation.

This does not make TLS useless. Encryption still protects traffic against passive observers, and correct certificate verification blocks many active attacks. The lesson is that public PKI validation and service authorization are different layers. A high-value origin may need a narrower trust decision than “any public CA may issue for this hostname.”

The browser ecosystem had additional response mechanisms in this incident. Chrome blocked suspected certificates through CRLSets, worked with CAs on revocation, and used Certificate Transparency logs to identify more affected organizations. A private API client or gateway may not receive the same product-specific emergency block quickly, so operators need their own detection and trust controls.

Start by Enabling Real Upstream Verification

Before adding advanced controls, verify that the gateway actually checks the upstream certificate. Encryption without verification can protect against passive capture while still allowing an active attacker to impersonate the origin.

Version details matter. The Apache APISIX 3.19.0 release notes state that upstream.tls.verify now controls certificate verification for https and grpcs upstreams. In the preceding behavior described by the release, the field was read only for the Kafka scheme. Teams upgrading from an older release should not assume an existing verify: true value had already enforced HTTPS verification; they should test the exact deployed binary and runtime.

For a protected upstream, the gateway should verify the certificate chain and the intended server name. When nodes are addressed by IP, make sure the gateway still sends the correct SNI and verifies the certificate for the service name. A successful TCP connection or encrypted handshake is not enough.

API7 Gateway 3.9.x documents upstream mTLS with a client certificate presented by the gateway and optional validation of the upstream server against configured CA certificates. The documentation also records a configuration-path exception: ADC accepts verify but not an inline ca_certs field, so it falls back to the system CA store when verification is enabled. That difference belongs in rollout tests because the effective trust store changes the security boundary.

Narrow Trust for Sensitive Origins

Public roots are appropriate for many Internet services. For an internal or tightly controlled origin, a private CA can reduce the issuer set to one your organization operates or explicitly trusts. Configure the gateway to trust that CA for the upstream and issue server certificates only for the intended service identities.

Mutual TLS adds authentication in the other direction. The origin verifies a client certificate presented by the gateway, while the gateway verifies the origin certificate. This can prevent an attacker with only DNS control and a public server certificate from successfully reaching an origin that requires a private client identity.

mTLS is not automatic authorization. A shared client certificate used by every gateway instance identifies a broad fleet, not a tenant or end user. The origin still needs route- or application-level authorization where those distinctions matter. Certificate rotation, key protection, revocation, overlap periods, and failure recovery are part of the design.

Certificate or public-key pinning can narrow trust further, but hard pins create operational risk when keys rotate or emergency recovery changes the chain. Prefer a managed private trust bundle or a deliberately designed pin set with backup keys and a tested update path. Do not add a single permanent fingerprint to configuration and call the problem solved.

Use CAA and CT for Issuance Governance

CAA records let a domain owner specify which CAs may issue certificates. ACME extensions can further bind authorization to an account or validation method. These controls reduce the authorized issuer surface and can block some erroneous or hostile issuance paths.

They have an important exception. Google's incident guidance says CAA cannot prevent issuance while an attacker controls DNS. The attacker can alter the DNS policy along with the service record. Restrictive CAA still matters after control is restored, especially because CAs may reuse cached domain-control validation. Publish the policy, but do not describe it as a complete defense against authoritative DNS compromise.

Certificate Transparency provides a different control. Publicly trusted certificates used by Chrome must appear in public CT logs, enabling near-real-time monitoring for unexpected names or issuers. Monitor the complete domain portfolio, including parked and regional domains, and route alerts to a team that can decide whether issuance was authorized.

CT is detection, not pre-issuance approval. By the time an alert arrives, a certificate may already be usable. The response plan should include:

1. confirm the certificate and DNS change are unauthorized;
2. restore authoritative DNS and registry access;
3. contact the issuing CA for revocation;
4. update gateway trust or block policy where appropriate;
5. inspect gateway, DNS, CT, and application logs for affected traffic;
6. rotate credentials exposed to the unauthorized endpoint;
7. verify recovery from independent networks and resolvers.

Test Counterexamples, Not Just the Happy Path

A trustworthy rollout needs negative tests that challenge the main claim:

• A certificate has the right hostname and public chain but is signed by a CA outside the approved private trust bundle.
• DNS returns an unexpected address that presents a publicly valid certificate.
• The upstream certificate is expired, has the wrong SAN, or omits an intermediate.
• The gateway sends the wrong SNI because the node is configured by IP.
• Server verification is enabled, but the expected custom CA is absent from the effective trust store.
• The origin requires a client certificate, but the gateway presents none, an expired one, or one from an untrusted client CA.
• The certificate rotates to an authorized backup key during an incident.

Record where each failure occurs. TLS failures happen before the HTTP request reaches the application and often surface as a gateway 502, but the exact status and log message depend on the product and configuration. Do not promise an application-level denial response for a handshake that never completed.

This discipline complements the two-boundary model in API7.ai's guide to TLS key exchange for gateway origins. That article focuses on negotiation compatibility and latency; origin trust focuses on whether the endpoint should be accepted at all.

An Origin Trust Checklist

For every sensitive upstream, document:

• the authoritative service name and expected SNI;
• the DNS zone, registrar, registry, and access owners;
• whether public roots, private roots, or a managed pin set are accepted;
• whether the origin requires a gateway client certificate;
• the deployed gateway version and effective verification behavior;
• the certificate and client-identity rotation process;
• CAA policy and CT monitoring coverage;
• alert ownership, revocation contacts, and credential-rotation runbook;
• negative handshake tests and their expected gateway evidence.

Keep these controls proportional. A public documentation origin and a payment or control-plane origin may justify different trust stores and recovery requirements. The goal is not to reject public PKI; it is to make the accepted identity set deliberate.

Conclusion

The ccTLD incidents show that a certificate can be cryptographically valid and still operationally unauthorized. DNS control, certificate issuance, gateway verification, service authorization, monitoring, and response are connected controls, not interchangeable guarantees.

Enable real certificate and hostname verification first. For sensitive origins, narrow trust with an appropriate CA set and mTLS, then monitor issuance through CT and constrain it with CAA while preserving each control's limitations. Pin the configuration to the gateway release that actually enforces it, and test the counterfeit-but-valid counterexample before declaring the path protected.

Explore API7 Enterprise to manage upstream TLS, mTLS, traffic policy, and observability at a consistent gateway boundary while your DNS and PKI teams retain ownership of issuance and domain security.