DirectAdmin 1.54.0 Release Candidate

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,158
Hello,

We're pleased to announce the Release Candidate for DirectAdmin 1.54.0:

All changes listed here:
https://www.directadmin.com/versions.php?version=1.540000

New Features:

Bug Fixes:


As usual, the binaries are available in the pre-release section of DA:
https://help.directadmin.com/item.php?id=408

If you have any issues, please report them here to avoid duplicate reports :)

John
 
Thanks. But I am confused about this bug fix: E-Mail field removed from LetsEncrypt form: https://www.directadmin.com/features.php?id=2175

Because up until now, when a user install Let's Encrypt and type in the email, if the certificate is not renewed and is getting near expiry date, then Let's Encrypt will send a email to the email address used when installing the certificate. So why is this not needed anymore? Previous the email was indeed sent to Let's Encrypt, and it was used because Let's Encrypt sent warning to that user email if the certificate was not renewed.
 
I understand this:
If you’re a hosting provider, those notifications should go to you rather than a customer.
This seems logical to me, but how it's "fixed" now, only the admin email is used. This will make the admin responsible for every letsencrypt mail on the server.

But I agree with Ditto that admin should not be the only one. At least the resellers also should get this option so they can take care of their own customers and don't have to bother the admin when something goes wrong.
 
DA does auto-renew the certificate well before it expires.
If there are any issues with that, DA will send a Message System notice about the error, and they can then take action.
The extra emails from LE shouldn't really be needed.

John
 
I agree with Richard! An example:

I request an SSL certificate for directadmin.com and www.directadmin.com and that works. Ten days later I decide to request a new certificate for directadmin.com, www.directadmin.com and mail.directadmin.com. Then Let's Encrypt sends an e-mail that the certificate of directadmin.com and www.directadmin.com expires. (rightly remarked)

That would mean that the 'admin' in this situation will receive an e-mail every time. That is not desirable. Can't be chosen for the e-mail address of the user?
 
what about forcing users use two-factor auth?
it will be great!
 
I understand this:

This seems logical to me, but how it's "fixed" now, only the admin email is used. This will make the admin responsible for every letsencrypt mail on the server.

But I agree with Ditto that admin should not be the only one. At least the resellers also should get this option so they can take care of their own customers and don't have to bother the admin when something goes wrong.

=====

Ok, we have 2 options:
1) We can remove the email from being passed to LetsEncrypt entirely.
DA will still notify the proper people about any renewal failures well before the certs expire already, plus it has many controls on who to send the DA notice to already.
If we go this route, may need to provide instructions on how to force the script create a new key on current boxes without any email associated (if the admin no longer wants email)

2) Or.. a directadmin.conf option like:
per_user_letsencrypt_key=0|1

where it can be set to 1.
The script would figure this out, and if set to 1 will send the emails to the email value in the given User's user.conf file.
However, the same LE email issue can come up if a new cert is requested, and the old different cert is left to expire, which would still cause confusion for Users.

=====

I'm personally in favor of #1 since DA does notify people, give the Admin control as to who to notify, and does not send confusing emails about non-applicable cert renewals.
Let me know ASAP as I can squeeze the setting into the directadmin.conf before 1.54.0 is released, even though it wouldn't have any effect on the DA binaries, only the letsencrypt.sh script (variable obtained by the script via './directadmin c')

John
 
I think I like option 2 best, because then the each admin can have the option to decide for themself. For example I would like to continue to use option 2 mostly because I don't want to do a conversion from the current setup (wich works fine) if I don't have to.
 
After thinking more about it, I think I would prefer option 1. However I am afraid that if we during conversion when we need to create a new key for current users, then I am afraid all certificates would be renewed? If so, then all certificates currently installed would be set to renew on the same date in the future, and that would be bad. Currently all certificates are installed on randomly different dates, and I would like to keep it that way to avoid extremely many renewals on one particular date (because of a conversion to use a account without user email).

What I am trying to say, is that if we can convert all current certificates to option 1 without reinstalling the certificates at the same time, then I vote for option 1. If not I would like option 2.
 
I would like option 2 more, because then admins can have more of a choice.
Indeed users might get more confusing messages, but that means the admin gets less of those if they don't want them. That's the reason I would like this more. Choosability=flexability.

However, if others rather like option 1, then I hope it can be done like ditto said:
is that if we can convert all current certificates to option 1 without reinstalling the certificates at the same time
 
With option 2 we get a discussion about what the default value should be.

I like option 1 better because of this explanation:
DA will still notify the proper people about any renewal failures well before the certs expire already, plus it has many controls on who to send the DA notice to already.
 
I've added:
letsencrypt_account_email=0

to the internal DA setting for now, and we'll update the letsencrypt.sh later.
It does nothing in the DA binaries, just stores the setting.

We'll then likely have it do
Code:
letsencrypt_account_email=0 - no email is created with the new global Let's Encrypt account.
letsencrypt_account_email=1 - admin only global letsencrypt.key, so that email would get all notices for all domains on the server.
letsencrypt_account_email=2 - per-user letsencrypt.key, for per-User letsencrypt account and LE email notices (not recommended by LE)
of course, existing servers would need some changes if they don't want the email to be sent over anymore, but for now, just use the "Unsubscribe" URL in any one of those emails, which should fully stop them.

John
 
This is a great solution imho. But if I'm the only one asking, I don't mind going with the majority and have it like you initially stated (so option 1).
 
That seems like a good solution John! :) server administrators can then choose an option for themselves.
 
@DirectAdmin support, As long as the conversion for existing certificates does not require that all existing certificates is renewed at the same time (the time of conversion), I don't think we need the option letsencrypt_account_email= , but I think we all could be happy with option 1 on your reply #9 above.

However we would hit a limit for some of the domains if all existing certificates was renewed at the same time of doing the conversion. Please clarify what the consequence of a conversion to option 1 in your reply #9 for existing domains would be?
 
If you going to use admin's email for all Let's Encrypt certs, please make Directadmin to check first that email account is valid and MX records are fineL

Faced the same error as mentioned here https://forum.directadmin.com/showthread.php?t=56822 today. And as an user of a hosting which faces this error it's very very unclear what to do. And the user can not do anything but contact hosting support. So probably you need to check first that admin's email is valid?
 
Back
Top