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

[DanB35]

As far as I can see when testing if you go to a IP address you get served a locally generated certificate rather than a Letsencrypt one as Letsencrypt certs are only generated for a FQDN whereas you are trying to access the site via IP.

No, not really.  There's no case where an (unmodified) SME Server is going to serve different certs depending on the requested hostname--that would require SNI, which SME doesn't support out of the box.  There's a bug open requesting that be added; I'm uncertain of the value of doing so, but in any case it isn't there now.  SME serves a single cert on any https connection, irrespective of the requested hostname.  You can verify this most easily on my site using Firefox--browse to the IP link I gave, Firefox will give you a warning, and let you view the cert.  The cert you'll see is a Let's Encrypt cert.

At this point the user is issued a warning by the browser that the certificate (self signed locally generated) is insecure.

No, the warning is given because the hostname requested (the IP address) doesn't appear on the cert.

[guest22]

How about we combine this all valuable knowledge into a wiki page. Terry indicated the importance/interesting nature already.

[ReetP]

No, not really.  There's no case where an (unmodified) SME Server is going to serve different certs depending on the requested hostname--that would require SNI, which SME doesn't support out of the box.  There's a bug open requesting that be added; I'm uncertain of the value of doing so, but in any case it isn't there now.  SME serves a single cert on any https connection, irrespective of the requested hostname.  You can verify this most easily on my site using Firefox--browse to the IP link I gave, Firefox will give you a warning, and let you view the cert.  The cert you'll see is a Let's Encrypt cert.
No, the warning is given because the hostname requested (the IP address) doesn't appear on the cert.

Thanks Dan. I just got back and tested and indeed this is correct.

Go to the IP and you get a privacy error. Check the certificate and you can see that the certificate is a Letsencrypt cert and the browser throws the error as the cert is for a FQDN and not the IP.

The browser continues to complain, despite the connection being https.

It reports:

Certificate Error
There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).

Secure TLS connection
The connection to this site is using a strong protocol version and cipher suite.

Secure Resources
All resources on this page are served securely.

So, yes the connection is secure, but the browser doesn't like it.

Possibly in the short term it may be easier to add a template fragment to redirect IP addresses to the FQDN is that is a concern for some ?

Inevitable StackOverflow:

http://stackoverflow.com/questions/11649944/apache-httpd-conf-for-redirecting-ip-to-hostname#11651783

There are lots of pages on the subject.

[DanB35]

Possibly in the short term it may be easier to add a template fragment to redirect IP addresses to the FQDN is that is a concern for some ?

Sure, though that does leave a couple of issues:

• You'll still get the certificate warning when you first connect, as it's the redirect happens once the connection has already been negotiated--but once it redirects you, everything in the address bar should look fine.
• Since every SME server has multiple hostnames, it may be difficult to determine the appropriate FQDN.  A reasonable first guess would probably be www.$PRIMARYDOMAIN, but even with only one domain that might not be the best answer.  If you're serving multiple domains, the odds of that being right drop rapidly.

[Stefano]

Sure, though that does leave a couple of issues:

• You'll still get the certificate warning when you first connect, as it's the redirect happens once the connection has already been negotiated--but once it redirects you, everything in the address bar should look fine.
• Since every SME server has multiple hostnames, it may be difficult to determine the appropriate FQDN.  A reasonable first guess would probably be www.$PRIMARYDOMAIN, but even with only one domain that might not be the best answer.  If you're serving multiple domains, the odds of that being right drop rapidly.

that's why, IMO, this is not an issue with a technical solution

[DanB35]

So, is https://$IPADDR secure?  Neither I, nor Chrome, nor Firefox, can tell you; only you can determine that.  What do you mean by secure?  That question isn't rhetorical--what do you mean by it?  Only then can anyone answer your question.

RequestedDeletion, my question from yesterday morning remains: what do you mean by "secure" in this context?  Only with your answer to that question can this conversation reasonably continue.

[guest22]

RequestedDeletion, my question from yesterday morning remains: what do you mean by "secure" in this context?  Only with your answer to that question can this conversation reasonably continue.

Well, secure has indeed a broad spectrum, so let me limit it to the meaning of a certificate by means of using http traffic.


So 'secure' in this respect is the connection between the client browser and webserver that is browsed to. Secure connection... This commonly shown as the 'green lock' (banks etc stress this very much). So the consensus is a green lock is 'safe', and all other scary screens are NOT safe. The 'green lock' concept will have users say 'That site is not safe' if it is not there.

[Stefano]

as it has been explained before, the green lock is not strictly related to https cert..

for example, a mixed content (https served page with some http content inside) issue will be reported with no green lock..

it's not a technical issue: you have to know how to decipher what your browser is telling you, reading the error message

[DanB35]

So 'secure' in this respect is the connection between the client browser and webserver that is browsed to. Secure connection...

Using the word "secure" to define the word "secure" is not valid.  But it sounds like you're saying one of two things, and I can't tell which:

• You have no personal definition of "secure" in this context at all, or
• "Secure" means that a browser says it's secure

If the former is the case, I don't know that the discussion can continue, at least until you do decide what characteristics define a "secure" connection.  If the latter is the case, then the scenario we're describing is simultaneously secure and insecure.