Hi, Thanks for your assistance earlier Till (not sure if you will read this - but appears you read everything!! ). Anyway, after following your suggestion to update my servers to use the git-stable (all servers now report under monitoring as 3.1dev) - anyway that is a side note. So thought I would try 'letsencrypt' on one domain and noticed the .vhost config got created and certificates issues by LetsEncrypt - but Apache failed and reverted to the original .vhost and renamed the failed '.vhost.err' to prevent Apache from not starting (obviously by design). However when looking at the SSL folder I noticed all shortcuts included a '-le' (e.g domain-le.crt domain-le.key etc). - but looking at the .vhost file it was looking for the names without the '-le'. Looking at the code for the 'apache2_plugin.inc.php' lines 1171 to lines 1174 (as per below) - appears to be where the shortcut filenames are generated:- Code: $key_file = $ssl_dir.'/'.$domain.'-le.key'; $key_file2 = $ssl_dir.'/'.$domain.'-le.key.org'; $crt_file = $ssl_dir.'/'.$domain.'-le.crt'; $bundle_file = $ssl_dir.'/'.$domain.'-le.bundle'; Yet the vhost file that is generated has a discrepancy with the filenames. So in order to correct this I have just changed the code on my server to remove the '-le' part - so the vhost files then match - thus everything then works. so :- Code: $key_file = $ssl_dir.'/'.$domain.'.key'; $key_file2 = $ssl_dir.'/'.$domain.'.key.org'; $crt_file = $ssl_dir.'/'.$domain.'.crt'; $bundle_file = $ssl_dir.'/'.$domain.'.bundle'; But it occurred to me that although this is a quick fix - there are likely to be other implications (that I am not aware of for example does this get written into the database) and should the correction have occurred on the generation side of the vhost. Anyway, thought it may be useful as obviously there is an error between these two sections. If you can advise of the best route for the correction - no doubt you have bug tracker standards that you follow and I have obviously just patched this for my own 'reckless' purposes. Thanks Rikski
Off course, when you update to a dev version that the version number shows that you run a dev version. Not sure when you updated to git stable as there were several commits today, the code that I tested an hour ago works flawlessly and has already been released as 3.1.1. The correct path contains -le in the path. Either your dev release does not contain the latest bugfixes yet or you use a custom vhost template which you did not contain the changes that were made for letsencrypt. Update to ispconfig 3.1.1 or update to git-stable again.
Hi Till, Thanks for the update - have again updated all servers last night to latest 'stable-git'. Ok, appears to work fine in regard to the certificates now - (correct naming throughout with '-le') and site is secured when accesing from https. However, now when I enter the website configuration - it does not have check marks against ssl and 'lets encrypt', which it did before the update last night. So guessing it is a bug? Hope it helps and any suggestion would be welcome. Thanks Rikski
There is no bug, the checkboxes are there. I guess you missed to enable ssl and letsencrypt for that client in the client limits.
nope, recreated website and checked lets encrypt - certificates generated and site works. But, re-entered site config and no ssl or lets encrypt check boxes against that website. Client limits check boxes tested in both disabled and enabled ssl and letsencrypt. Yet still does not show in site. Checked in database under 'web_domain' table - website has 'ssl' listed as 'n' and 'ssl_letsencrypt' as 'n' - so clearly not updating in database. Going to rerun again in debug - to see if error messages come up.
Ok, appears to be related to 'letsencrypt' script responses - and the handling of those messages. e.g. renewal conf file *.conf is broken. Too many certificates already issued for exact set of domains So can't really test anymore at present without doing more work setting up other DNS records etc. Sometimes the DEBUG :- Enable SSL for: [site name] is activated other times not. - so think it is related to unexpected responses from the certbot script.
Works fine here. The checkboxes must be disabled of course when letsencrypt is not able to issue a cert. Otherwise the checkbox would indicate a wrong status.