Hello, Since 2013 I have my own clouds, clients and platforms and switched from VestaCP to ISPConfig about 6 months ago. So, I'm new to this (awesome) Community, (fantastic) Panel and even bought and read the book. Thanks for all of this, btw! However, even after reading 500+ threads across various topics, 1 issue remains - requesting help. --- On a new server there are 4 different TLDs (.biz, .net, .asia, .cloud) with combinations of subdomains per client (xx.domain.asia, xy.domain.cloud) plus the main domains (domain.biz). All domains use SSL with their respective client settings, and so far - with a lot of experimentation in the beginning - domains and subdomains have been added via DNS Zones, since A-records didn't seem to play well with Let's encrypt (or the certbot issue some months ago) 8 Domains are working WELL on that one single-IP server, I'm on the latest version (git-stable) using nginx only. The issue now is, adding a second (or third) subdomain to .cloud (v2.domain.cloud) "disrupted" the certificate from .biz After that I've tried pretty much everything, including adding/removing sites and records and certificates, using DNS zones as well as A-Records - not working. Also considered the delay between abvailability and SSL generation - nothing works. The server deliveres anything but the domain.biz. I understand that server requests take the "next best" match (i.e. in lack of a valid SSL?), and delivers SSL for either xz.domain.asia (there are 3) or xy.domain.cloud (there are 2 now, 2 more where removed) - even after bind9 and server restart. Removing the newly added domain entries and creating the .biz SSL anew (per klick) restored .biz and .cloud domains. (fortunately), but I'm stuck and can't get any more subdomains to work? Any Help or Hint is appreciated! Stay awesome, Regards, Martin (Bremm
Hi Martin, can you compare the created config files for the domains before and after the change? When it is not working correctly, can you verify, which certificate is used and which domain served by "openssl s_client -connect domain.in.question.cloud:443 -showcerts"
1) Ensure that all sites and all vhost domains either use * or the IP address, don't mix * and IP on a server or traffic will get routed wrong by apache and nginx. 2) When there is no matching SSL cert for a given domain or SSL could not be activated for a website, then this traffic gets routed to the first site in alphabetical order that has SSL enabled.
Gents, MYSTERY SOLVED, almost anyway: a) I was able to replicate things to compare all configs, only to find, that there were no differences - good one, though. b) I ALWAYS select the IP, double checked to be thorough, but then : all websites added before the recent update (?!?) showed *, all websites added after the update showed the IP. (which is when the problem first appeared) (To be fair: not sure IF * is directly related, or was caused by any of the other actions to mend the situation, it's an observation) 2 Years ago I had a situation, where certbot removed 30 lines from a domain.nginx.config file including the last parenthesis. Since I'm firm in multi-server environments using HA-Proxy, fixed IPs are a hard requirement for me, and especially liked the IP-suggestion right from the beginning. I'm certain they were initially set. However, the current vhosts confirm the mix. - Thanks for the hint! 10 more tests show it's all good now, and I don't even need another zone or even A-record. Maybe there was something off before, but it's definitely working well now. Love the tool, THANKS again I'll keep reading and start helping as time allows. Regards, Martin.
