Topic: Letsencrypt protected websites accessible unsecure via direct IP opposed to FQDN

[guest22]

It appears that Letsencrypt secured websites on SME Server CAN be accessed via un secure http when one uses the IP address opposed to the FQDN. Can some readers check this on their own sites please? I may be at fault here, don't know.

[ReetP]

Probably depends on your ibay settings. See modssl.

It isn't an issue with letsencrypt but your server setup I think.

[guest22]

Probably depends on your ibay settings. See modssl.

It isn't an issue with letsencrypt but your server setup I think.

I have no ibays on this test server, clean install, updates and then letsencrypt.

[Stefano]

I have no ibays on this test server, clean install, updates and then letsencrypt.

so can you make an example?

how did you setup the websites?
are they using https?
are you forcing https?

[guest22]

so can you make an example?

how did you setup the websites?
are they using https?
are you forcing https?

As per my earlier comment above. Clean install, updates and manually letsencrypt according to how-to. That's all. No ibays, no websites, nothing, just the primary by default

[Stefano]

I remember a bug about SSL and Primary ibay.. check BZ, please

[guest22]

The _only_ way around this is to set the main domain to be served from an ibay, and leave the Primary 'empty'/not use it.

[janet]

The _only_ way around this is to set the main domain to be served from an ibay, and leave the Primary 'empty'/not use it.

That has been "recommended" practice for many years.

This is the bug I think Stefano is referring to.
https://bugs.contribs.org/show_bug.cgi?id=9193

[guest22]

Then I guess we have a serious security issue with SME Server out of the box with the Primary ibay. Especially since letsencrypt wants to write to it's acme directory via http and when the Primary is set to httpS only, it won't fly. Chicken and egg?

[guest22]

I guess especially when self signed certificates are less and less accepted and present scary warnings to browser users such as Chrome and Firefox.

[DanB35]

Then I guess we have a serious security issue with SME Server out of the box with the Primary ibay. Especially since letsencrypt wants to write to it's acme directory via http and when the Primary is set to httpS only, it won't fly. Chicken and egg?

That shouldn't be a problem--the Let's Encrypt servers will follow redirects, and won't complain about self-signed certificates.

What I think you're running into, though, is the fact that the server's IP addresses (internal and external) aren't on the certificate, so if you try to browse to your SME server by IP address (i.e., going to https://$IPADDR), you'll get an error.  If you go to my server, for example, https://www.familybrown.org, you'll get an https page with a valid Let's Encrypt certificate, and no issues.  If you instead try to go to https://96.91.11.81, you'll get a certificate error.  That's normal, and it's just part of how TLS certs work.  No CA will issue a cert for an IP address, so if you browse to a secure server by IP address, you'll see an error that the hostname doesn't match the cert.

[guest22]

If you instead try to go to https://96.91.11.81, you'll get a certificate error.  That's normal, and it's just part of how TLS certs work. No CA will issue a cert for an IP address, so if you browse to a secure server by IP address, you'll see an error that the hostname doesn't match the cert.

Thanks. That is correct, but I can still proceed to your website by clicking advanced and proceed..... I am not blocked in any way and can access your site unsecure.

[DanB35]

I am not blocked in any way and can access your site unsecure.

Yes, but "unsecure" means, in this case, that the hostnames don't match.  The connection, and all traffic through it, are still encrypted.  If that's your concern, it's simply a result of the way that public CAs (any public CA, not only Let's Encrypt) operate--they don't issue certificates for IP addresses, they issue certificates for hostnames.  If you buy an OV or EV cert, the cert contains additional information, but the CN and SAN fields will still only contain hostnames, never IP addresses.

Don't want the error?  Browse by FQDN, not by IP address.  That really is the only way to avoid it.

Edit:  What is the "serious security issue" you see?  Because nothing you're describing sounds like a security issue at all.

[guest22]

Edit:  What is the "serious security issue" you see?  Because nothing you're describing sounds like a security issue at all.

Let me get this right based on what you are describing. So I go to your server to access an web application. I do this via IP and not via FQDN. I get the warning, bypass the warning and access the web application, let's say Nextcloud. Do you mean to say that all http traffic is secured?? Whilst there is no green lock? (let's forget about the internal Nextcloud redirects to FQDN)

[DanB35]

Do you mean to say that all http traffic is secured?? Whilst there is no green lock?

Does the URL say https:// ?  If so, then yes, all the traffic is encrypted.  You can confirm this yourself on my site, depending on which browser you're using.  Using Chrome, I don't see any easy way to confirm it; it just gives you the red "not secure" warning.  But if you use Firefox, you'll get the green lock (after you add the security exception).

The problem is that security isn't binary.  Chrome says the site is insecure, because the hostnames on the certificate don't match the hostname in the address bar.  In most cases, that would indicate a MitM attack.  Firefox says the site is secure, because the connection is encrypted.  Which is right?  It depends on what you're trying to do.  If you go to your bank's website and get a certificate mismatch, you have a problem, because you probably aren't communicating with who you think you're communicating with.  But if you browse to the known IP address of your server and get that error, and the certificate doesn't have the hostnames that belong to your server, you really don't have a problem.

This could be avoided by implementing a redirect from https://$IPADDR to https://$FQDN, but that raises the question of which FQDN to use--a stock installation of SME Server will have several hostnames assigned to it, and it's very common for the server to be hosting multiple domains as well (each with its own set of hostnames).