Anyone here using ISPconfig to manage their domains and using quic.cloud? Deployed a new fresh domain (that had never had an LE SSL issued via ISPc) to test my previous problems. Same thing happens with new domain (cname only added as quic requires) pointing to my ispconfig (single ip) server, and new domain is also redirecting me to the default domain instead of persisting to this new domain. I have other domains also on this single IP ISPc server that work well and not configured via quic.cloud. All domains too have been selected using IP and not * under ipv4. Also no redirects set from Redirect tab. After checking with the great supports folks at quic.cloud it appears its some server issue (IPSconfig). Any ideas how to fix this redirect issue happening on these few domains that I am using on quic.? Noticed this mentioned by Till on another thread: Wrong redirects have normally one of these two causes: 1) Don't mix * and IP address in the Ipv4 field of the websites. Check all sites. 2) When using SSL, then all sites that point to the same IP address must have SSL enabled. But if 2) is I understand, then it will not allow to use an external provider with their own SSL if I have to disable or not use SSL from ISPc. Am I reading this right that all domains when ISPc is on 1 IP that all domains must have an SSL issued by ISPc? Plus, if my ISPc server is isp.domainX.com what sets my default domain that is being redirected to, domainX.com is it cause its the root domain of my ISPc hostname or some other setting has made this my default domain being redirected to? i.e could this be set to be some other default domain to fallback to? Overall, why are these redirects happening to get a better understanding? Related to having external SSL (on such reverse proxies), using 1 IP and not knowing to direct to the right domain? If this is the case, isn't this something ispc should handle or if we can enforce it? On Ubuntu/Apache and still on: 3.1.15 Thanks ahead of time.
I never used that service that you are trying to use, so I can't say anything specific to them. If you use an external provider or not does not matter. You just have to take care that you either enable SSL on all sites of the same IP or don't enable SSL on any of them. The reason is this: when a request for domain b arrives on SSL port 443 and only domain a has SSL, then apache and Nginx will route traffic for domain b to domain a as having the correct port has a higher routing priority than having the right domain name via SNI. What you should try is to test the websites locally to see if you get the right site.
How do you mean? I have other domains with enabled LE SSL via ISPc and they work fine. Only when I am using this remote service things fail. I have not tried similar with cloudflare, but I assume it will be similar. So what is the ideal setup when using Cloudflare? Do we keep locally SSL disabled while we have it enabled on cloudflare? Since they (remote quic.cloud) can issue also the SSL cert, don't I have to also not enable SSL on this domain on ISPc side, as I assume there will be issues having both remote and my ISPc for that domain enabled for SSL? If that is the case, then this domain will not have SSL locally. Unless I enable also locally but not checkbox LE SSL to be issued?
I explained to you how apache and nginx work to help you to better understand possible problems. If you are using LE or not does not matter for this. If the system that you use does not block let's encrypt domain based authentications, then you should be able to activate LE for the sites in ISPConfig as well. This would be the more secure way, but even a self-signed cert might work in this case. Encrypting the link between your cloud provider and your server is recommended, otherwise this part of the data transfer would be unencrypted even if you have SSL enabled at that cloud service.
Got it working eventually. Went direct to get LE SSL issued from ISPc for domans. Checked all domains and made sure they all had SSL enabled (some not LE and no other SSL) and then pointed back to quic and its hitting the correct domain as it should. Thank you sir Till.
Back to this again, Trying to make www redirect to non-www work. So not sure if we need to enable from ISPc side also per domain redirects such as type R=301,L with an SEO redirect of www.domain.tld => domain.tld and also if needed to Rewrite HTTP to HTTPS or not? If I do set these redirects, do I need to maybe do this for all other domains too, due to as we mentioned need to have SSL enabled for all domains in ISPc maybe? To summarise, quic.cloud wise, works best with CloudFlare since you do not set an A record but instead a Cname record i.e domain.com to xxxxx.quid.cloud (they issue). So we have no A record in CF besides for mail.domain.com pointing to ISPc IP. quic also has option to issue SSL for 'www & non-www' or just Not (if not its just for domain.com with no www). It also assumes the www as an alias so no need to add it as an extra option. In CloudFlare I added a CNAME for www alias to domain.com Testing various ways via some online tools I am seeing at times SSL cert warnings on https://www.domain.com and other times again defaults back to default domain (not domain.com desired) of the ISPconfig server. This is a WP site and using the simple SSL plugin that also checks for SSL if available and sets its redirects. Also have an option to enable from this SimpleSSL plugin .htaccess 301 redirects that I have enabled for now. Where have I gone wrong in this setup?
Only choose the SEO redirect, leave all other field untouched on the redirect tab. Do not use online tools, not all of the support SNBI which must lead to wrong results. just enter the URL in the browser on your desktop to check if it works.
Thank you sir. I did set this last night with only with SEO Redirect www => domain.tld but with type also set to R=301,L and it appears its working till now, (with no Rewrite HTTP>HTTPS set). So I guess type: R=301 I keep or remove? but yes as you said below, Glad you said this, cause they baffled me. Any that are worthy to consider that support SNBI at least? Thanks again.
Use your web browser, it does all that you need to test if SSL is working correctly for a site. Enter the URL of the site with https:// in the address bar of the browser, if it shows the right site and if it does not show a SSL warning, then you're ready to go.
Hi again, Again, this ended up going to default domain of ISPc. Trying also on other domains that are direct from cloudflare to my ISPc and the same happens (to isolate its not quic). so any time I add a 'www' in front as such: www.mydomain.com it ends up redirecting to the ispdomain.com on my ISPc server with hostname: isp.ispdomain.com instead of hitting https://mydomain.com CloudFlare CNAME (www is an alias for mydomain.com) or also when I try A record www => direct to ISPc server IP (only one IP) If I either enable from websites > domains > Redirects to: No redirects or www.domain.tld => domain.tld with or without and type R=301,L (with or without) does not fix the problem. Disabled also all WP plugins handling redirects such as SimpleSSL via WP or .htaccess. Where could the culprit be in this time? It was working for a few days and when I checked its back to the same problem * All domains have SSL enabled via LE hosted on ISPc server. * Auto-Subdomain: None Do we need to manually add code to .htaccess when I would consider this hackish when I think ISPc Redirects should help here? Appreciate the help on this.
No. It's not easy to say as the problem is most likely not related to ispconfig. ISPConfig does not alter the website config in any way, unless you instruct it to alter it by editing the site settings. This means, the config was correct as it worked, the config was not altered, so the problem why this happens again is not the server configuration. Checky our DNS records for inconsistencies, it might be that not all dns servers of your domains are in sync. This would explain why you experience this just periodically.
Other reasons for getting a wrong site might be typos in the domain name. auto subdomain www means that www.yourdomain.tld is assigned to this site. But when you e.g. accidentally type in we.yourdomain.tld or vww.yourdomain.tld, then a wrong site must show up as the domain entered in the URL bar of the browser does not match any domain of that site.
Deployed a new instance of ISPconfig, using the OVA Debian 10 Apache on a set of new domains just to test this out, in case it was my previous ISPc setup and the outcome is the same problem appearing This is the current example setup: https://buster.myispc.com:8080 secured via SSL by following this: https://www.howtoforge.com/tutorial/securing-ispconfig-3-with-a-free-lets-encrypt-ssl-certificate which requires a setup of a website myispc.com which has been done and both (website and panel) work under https:// When adding a new site, 123.com (with auto domain set to None) and playing with SEO redirects www => domain.tld nothing seems to get the www.123.com resolve to 123.com but instead goes to myispc.com with a cert warning since 123 cert does not match the myispc one. I have never used DNS section within ISPc, so maybe this is required to add zones and records from within ISPc instead of relying and to solely use external DNS providers? This is a new clean setup and the problem has been replicated. Note: none of these domains are handled by quic as by this subject of this ticket and its actually namecheap Advanced DNS with these 2 records either 2 A or 1 A+1CNAME for www.
It does not matter if you hoste the DNS records externally or in ISPConfig. This indicates that you must have configured something wrong because when the issue is not the setup and not ISPConfig in general, then all that remains is what you entered in ISPConfig or what you configured outside of ISPConfig in regard to DNS or other things like routers etc. Maybe you should consider contacting Florian from ISPConfig business support team to have a look at your server and domain directly to sort out your problem.
After long attempts, this is the solution for those that are battling with this issue www > domain.tld The issue is even though I mentioned it that Auto-domain is set to NONE many times, it was not indicated that it needs to be set to WWW 1st and then have SSL LE issued. Otherwise as I understand it, LE will not issue with a www alias or part. Then set Redirect for www.domain.tld => domain.tld IMHO, next to checkboxes of LE/SSL there maybe should be another checkbox such as "Also issue SSL for WWW Alias" if this is not what Auto-domain is meant to be for. Am I right @till or is this just that I got lucky and it will only work temporarily you think?
