SafeLine WAF: Why IP Access Returns the Default SSL Cert

If you're using SafeLine WAF or any reverse proxy with SSL enabled, you might encounter a confusing situation:

When accessing your site via IP address instead of domain name, it returns a completely different certificate — often the default one.

Let’s break down why this happens, and why it’s not a bug but a behavior defined by the TLS standard.

The Issue: SSL Works with Domain, Fails with IP

Imagine this setup:

• You configure a SafeLine site using your domain example.com.
• SSL is enabled, and a proper certificate is applied.
• You access https://example.com — everything looks perfect.
• But then you try https://192.0.2.1 — and boom, you get a certificate mismatch or the default SafeLine certificate.

Why This Happens: TLS Happens Before HTTP

Here's the key insight:

TLS handshake happens before the server ever sees your HTTP request.

That means the server doesn’t know what Host header you're using — because it's encrypted inside the TLS payload.

So how does it know which certificate to send?

The answer is SNI.

What’s SNI and Why IP Doesn’t Work

SNI (Server Name Indication) is an extension in the TLS Client Hello message that tells the server:

“Hey, I’m trying to reach example.com. Please give me that cert.”

But here’s the catch:

IP addresses are not supported in SNI.

That means when you access your site by IP, your browser/client doesn't include the Host name in the handshake. And if the server can’t see the domain, it can’t choose the right certificate.

So SafeLine (and most other web servers) fall back to whatever certificate is tied to the default virtual host.

Why SafeLine Returns Its Default Certificate

When no SNI is provided (as in IP access), SafeLine does the following:

• If a site is marked as default_server in Tengine (Nginx), it uses that site’s certificate.
• If no default site is configured on that port, SafeLine returns its built-in 404 fallback site, located at:

<safeline_install_dir>/resources/nginx/sites-enabled/IF_backend_not_found

This fallback site uses the SafeLine default SSL certificate, which is what you’re seeing.

✅ How to Avoid the Problem

Here’s the TL;DR:

To avoid the issue:

• Always access SSL sites via domain name, not IP.
• Don’t rely on IP access for SSL testing or API calls.
• If you must support IP access, consider using a self-signed cert just for IP — but this comes with limitations.

🧠 Final Thoughts

This isn't a SafeLine bug — it's how TLS and SNI are designed to work. Once you understand the role of SNI in certificate negotiation, this behavior makes perfect sense.

And if you're building secure infrastructure, knowing this helps you avoid misconfigurations that lead to SSL errors and angry users.

Join the SafeLine Community

• GitHub Repository
• Official Docs
• Discord Community

Need an open-source WAF that actually explains what it's doing?

Give SafeLine a try.