According to server.sh, the subdomain is neither reachable from your server nor outside your server (as LE tries to connect to it from its own servers and not from your system). So, it's not a DNS resolution issue on your server, and ISPConfig correctly denied requesting it via LE as it is indeed unreachable. Therefore you can disable the skip let#s encrypt checkbox again. The next question is, did you add anything in the custom nginx or apache directives field of the website or do you use any custom config via directive snippets? Or do you use any .htaccess config on apache that might deny access to the .well-known/acme-challenge/ in the website (this is a virtual URL, so do not expect that such a folder exists in the site).
And one more point, if this subdomain exists as an IPv6 address (AAAA record), then IPv6 access must work, as LE prefers IPv6 over IPv4.
Ok, you´re possibly pointing me to the right direction. This sub domain is used for a seafile installation and therefore has some special Apache directives which may be the root cause. But this sould be a common case and not blocking LE certs. Pls. find the Apache snippet attached.
Ok, now the solution (google´s your best friend): Add this line to the Apache directives: ProxyPass /.well-known/acme-challenge ! Thks. to all for your help.
Problem solved, add this line to the Apache directives (at the top) and anything goes fine. ProxyPass /.well-known/acme-challenge !
Yes, using a proxy directive without that redirects all requests intended for LE to the proxy target instead of the ISPConfig server where the LE client is run. The result is that neither ISPConfig could test the domain nor LE could issue a cert.
how about native support for domains behind a proxy? nodejs and for docker for sure? Probably already in youe mind? @till stuff like this could be handled by ispconfig or maybe more correct, domains in front of a proxy ^^
You can have domains behind a proxy with ISPConfig, many do it and there are no issues at all. The above issue is not a domain behind a proxy anyway, it's about manually proxying LE requests from ISPConfig to a proxy target. If he had used the proxy option on the redirect tab of the website, then ISPConfig would have added this directive automatically. But when you override ISPConfig config manually with custom directives, then you must take care that your manual config is correct, and this was not correct.
I can't seem to find an easy entry on website setting where I could say [x] rewrite requests to backend which is: [_________] is it via ip mapping? Edit, nevermind, I found it on redirects ... too bad it only works for one path / allows for one setting only
yeah I was editing my post while you added this thanks, is still limited though :/ I had an old setup where I redirected some tools like /pma/ /grafana/ /elk/ /monit/srv1/ things like that. for nodejes and docker I'd expect more need of such
If you need advanced proxying, you can do anything through the Apache or Nginx directives tab or via the directive snippets function.
sure, but those are not valid alternatives in the sense of making ispconfig better. snippets imho should be just that, snippets you'd share with other clients or do some common tasks. specific backends for a domain are not such a thing. I'd prefer a redirects tab where multiple (proxy)-redirects could be easily entered, enabled, disabled. I think that'd be a quality of life feature. I'm not asking for it, but I think it'd be nice.
Sure, I might add some more advanced proxy options in the future. The problem is that the most often made complaint about ISPConfig is that it offers too many choices and settings already. So, adding even more config options might drive users away from using ISPConfig. And you can do all these things already using the apache and nginx directives.
plesk - and others - offer a simple and advanced view. simple view could be what it is now, advanced would unlockthe foreach? Well the most complaints I receive, whenever I try to make people use ISPConfig, is the UI. Maybe autohide some features which depend on things not enabled might make a cleaner view of things, or just some better categories. Working with the ispconfig api right now, thank you for json by the way, and yeah... it really is a patchwork and could use some heavy redesignsat some points. Though I think I can estimate the cost of such a thing and have to admit, probably nothing for the near future ^^
Yes, I know. It needs an overhaul graphics-wise. ISPconfig already hides features based on the limits that you set for a client or reseller. Only the admin sees them all. And you can even hide unused modules for the admin as well under System > CP user, if you want. Yes, doing this easily costs a mid-5-figure EUR amount.
And if you deal with companies that use ISPConfig but complain that they lost the copy of their ISPConfig manual and their download link is not available anymore after 7 years, and instead of buying a new one for 5 EUR, they request that I send them a copy of their manual version by email. Then you know how utopic it is that someone will fund an API redesign
maybe just needs some redesign then. Plesk has tons of bloat and somehow it is loved still and they hide it somewhat neat at some places. It's still a pain to have such setups in the fleet ^^ yep, I can relate to that feeling, unfortunally. And worse. Well 7 years ... 3 years to go, then you can say not even RedHat gives support that long =) *cheer*
