Hi Everyone We have our web server hosting with some websites someones with ssl others without ssl. The server work with apache 2.4 and the server is managed with ISPConfig. I note this behavior: If I write in the browser https://site.com. the browser (Firefox, chromium based browsers) show this: "The connection is not private Attackers may be trying to steal your information from site.com. (for example, passwords, messages or credit cards)" We note the issue happen when the site have a SSL, because if we try with a site wihtout SSL the server respond correctly and drop the dot of the FQDN. Of course this behavior is not exclusive to our server, because we have done tests with other international domains that have a SSL certificate and the error happens and the error message that is received is "Bad Request - Invalid Hostname". In other domain the issue not happen and redirect the url correctly for example https://google.com. and drop the dot of the FQDN. So we think there could be a bad configuration on the apache server, or a htaccess wordpress misconfiguration, or maybe is normal behavior of the https protocol or something like that. We try to see the logs of the server with tail -f to see what can be the error that is happen, but not get anything that could help us. Then we whant to ask to the forum if someone had have a behavior like that with Apache server and we we whant to know if is posible to solve.
So, if I read this correctly, you don't understand why the connection is untrusted on https when you enabled SSL on your server. This happens when you don't have a valid and trusted SSL certificate. You can get one for free by enabling the Let's Encrypt checkbox.
I think @andresgt2000 means the following: given a website with certificate like https://howtoforge.com that works, then adding a dot at the end of the url makes it not work. I tested a bit, OP is right. But it does not happen on all websites. My understanding has been that DNS name service names can have a dot added in the end, the dot is the toplevel domain. So the dot is not wrong here. For example, for howtoforge.com it still goes to correct place with dot added. But sites on my ISPConfig setup suffer from this, the dot added makes it go to the domain that is first in alphabetical order where I do not have certificate (I have added 0000aaaa -domain to catch cert errors and misconfigurations). It looks to me ISPConfig setups have this problem, at least on my setups. I do not understand why this happens, but guess it is web server (Apache in my case) that does not recognise domain.tld is the same as domain.tld. (note the . at end).
@Taleman: Howtoforge uses Nginx, so the difference might be the behavior of Apache and Nginx web server.
from dns-sd.org: so I guess what ispconfig should be putting into the apache vhost conf, for eg example.com is not: Code: ServerName example.com ServerAlias www.example.com but Code: ServerName example.com ServerAlias www.example.com ServerAlias example.com. ServerAlias www.example.com. although I guess, technically, www.example.com. would be the FQDN and should be the ServerName entry, but it makes no effective difference.
Just my opinion: I've never seen that someone entered or used a domain with a dot at the end in the web browser and that it took 15 years of ISPConfig development that someone even noticed that apache does not redirect it to a website by default speaks for itself. So I would say, if someone really wants this, then he can add domains with dot as alias domains in ISPConfig and in case the Regex filter blocks that at the moment (have not tested that), then we could just allow it in the regex, but only for alias domains.
yeah, i'm not actually bothered about it, never seen it as an issue, never even thought about using the trailing . in a browser url myself, and I doubt many others have, and even the dns-sd site say's it doesn't affect all versions of apache. was just saying that I guess to be technically correct, they *should* be included in the apache vhost conf. although that would probably end up causing more problems for those who use lots of aliases and subdomains with letsencrypt certificates.
Exactly is like apache that does not recognise domain.tld is the same as domain.tld. (note the . at end), but only if call a domain that have SSL certificate.
Yes I completely agree with your comment Till, I also had not seen anyone put a dot at the end of a URL. But it happened to me and some clients are asking why that happens. Of course my response to the client is that please do not put a dot at the end of the URL. The strange thing is that I have a server mounted manually with apache, php for a company app, with SSL and when I apply the same test with the dot at the end of the URL, apache correctly directs it to the URL without dot. (I was remember that in front of this server we have a balancer appliance, then I think that balancer recognize the dot at the en end of the url and change to the correct url)
Yes we have valid and trusted certificates from vault CA. valid for 2 years, they will expire on 2022.
The reason might be this: The system has just a single vhost which also acts as a default vhost in this case, so it catches the nonmatching request and then the app itself redirects it or there is an additional apache rewrite rule in place that does the redirect for unmatched requests.
