Hey, that’s not my server!

We are often approached by customers and researchers asking why trusted, legitimate certificates are suddenly being served on hosts in some faraway country. Almost every case we looked into was due to the major content delivery network (CDN) providers, such as Cloudflare and Akamai not being intentional when dealing with null Server Name Indication (SNI) requests.

When you request “https://example.com”, your client, usually a web browser, initiates a TLS handshake. As part of this process, the client informs the remote server of the hostname it wants to connect to (example.com). This step allows the server to map the requested hostname to the appropriate SSL certificate before establishing a secure connection.

A well-implemented server would typically return a dummy/default certificate if the SNI request is null. However, many implementations instead serve a valid certificate for other (legitimate) domains that happen to match that null lookup.

Why does this happen?

When a certificate is seen on a host outside of expected ranges, it is a strong indicator the host is acting as a proxy, redirecting to a CDN range or a legitimate server.

Since TLS certificates are issued at the domain level rather than tied to specific IP addresses, an administrator can configure a proxy to transparently relay traffic between the client and the legitimate TLS service. As long as the client provides the correct SNI, the proxy can pass data unchanged, preserving the integrity of the TLS handshake. This makes the proxy indistinguishable from the legitimate TLS server.

For example, in the following two screenshots, on the left, we see a host in Russia running the Sliver C2 multiplayer server on port 31337, which in itself is suspicious, but on the right, if we scroll up to port 443, we see an HTTP(s) service running a legitimate (and trusted) certificate for microsoft.com.

The certificate is genuine, but the host presenting this certificate is definitely not owned by Microsoft – this is simply a trick – a proxy server to one of several Akamai hosts serving up the Microsoft.com TLS certificate when a client provides no SNI. In this case, it’s possible the actor set up port 443 to forward to Microsoft as a way of making the host appear legitimate on quick inspection.

You can try this yourself by searching for IP addresses that serve valid TLS certificates without requiring an SNI. Akamai and CloudFlare are good starting points, as they handle a significant portion of the internet’s HTTPS traffic and often do not respond with dummy certificates. Once you’ve found a server with a TLS certificate you want to replicate, you can use a tool like socat like this:

This creates a pipe between the local port 443 and port 443 on the remote server—now, your server looks authoritative for whatever TLS certificate was being served from the remote server’s bare IP address. Below, I have already established a tunnel between the localhost and 184.24.14.218, which is currently serving up a certificate for “intel.com.” We then ran a curl against localhost with the intel.com domain set as the SNI. Note that there were no certificate warnings during this request.

But is this bad? It’s hard to say. You won’t be able to view or tamper with any data transferring between the client and server being proxied, but one could use this to look “more legitimate” to an outsider. The reality is that these could be anything from a malicious actor trying to look legitimate to just a strange routing/proxy configuration. The point is to know how TLS functions when you see certificates pop up in unknown places so you don’t end up going down too many rabbit holes.

For a quick analysis, we looked at every certificate discovered on bare IP addresses within AS16625 (AKAMAI-AS), one of Akamai’s autonomous systems. We then searched for those duplicate certificates on non-Akamai networks, specifically on ports different from those used by Akamai. For example, if a certificate was found on Akamai’s port 443 but appeared on a non-Akamai host’s port 4444, it was counted. Additionally, we only included non-Akamai hosts that served the matching certificate while also returning the “Akamai Ghost” server header.

With these rules in place, we found just under 7,000 distinct hosts on the Internet doing 1:1 proxies to various Akamai hosts serving up legitimate TLS certificates on the bare IP.

Censys perspective

While legitimate certificates being seen on unexpected remote systems is cause for investigation, it does not always indicate malicious activity. With thousands of hosts acting as proxies and being seen by scanners with legitimate TLS certificates this behavior is one of the unique eccentricities of the Internet. While some of these proxies were likely intentionally deployed as a means of masquerading a malware control server as a legitimate third-party system, others are likely the result of unmaintained proxies redirecting to IP addresses that have changed owners.