Direct support for lets encrypt

[burner-]

What would you like to be added or enhanced?

EMQX dashboard should have direct support for lets encrypt as dashboard https conector and at mqtt conntectors.

Why is this needed?

Currenty it is possible cofigure admin panel behind ssl but it need quite lot of manual configuration. First touch of prodcut gives me feel that security as default is not in culture of this product development. It is more like addon. Also that default admin password give vibes that there is lot of work at developin proper security culture for this product developers.

These days many modern softwares what include web managmend have also just one click checkbox what allow enable lets encrypt for managment console and automatically keep care of getting certs and so on. That encourage to use encryption when ever it is possible (when service is in public network).
Encryption and other basic security shoud be default. Not addon what needs hours of manual configuration and set up scripts.

[zmstone]

Thank you @burner-
We might consider adding an ACME client in EMQX to make things easier.

Out of curiosity many choose to terminate TLS at LB though, that's not the case for you ?

[burner-]

I can do it with BL but its not a point. Point is to try engourage devs to do product what engourage users to not shoot to their own leg with security.
But honestly deeper I dive more worried I come security culture of EMQX. I am sorry to say that looks that lack of fast way to get TLS is just tip of iceberg at bad choises. If you want I can open different ticket from each one but at this point "basic things what should be clear without saying that not to do with this way" what I hit in first hour of use:
a) 0.0.0.0 binded admin console port by default. Admin console should bind only localhost by default because it have default password set.
b) no ssl by default at admin console. Even self signed cert would be better than http as default.
c) all listeners are enabled and bind to 0.0.0.0 by default without any authentication.
d) authentication allow policy by default. All listeners are open if no authentication is set. Good practise is that by default those are closed and admin can set anonymous authentication method what opens them for all if really wanted.
e) default password at admin console. Yes this is not so bad if admin console is binded to localhost. Anyway default password usually just brings false sense of security. That why usually it is keeped as bad design and recommended way is just remove login screen when no password is set. This is more like tweak compared to a-d

At that point I just shutted down that server and continue my holiday. I did not want to do full security review for that in my holiday what it clearly needs before it is safe to connect it back to internet. I think I return to this later but clearly there is place that your dev team do internal review for best practices. I dont want to be mean or anything but it is just big surprise to find so many "student solution" in same product what is so popular and targeted to be enterprise.
Do you want that I open tickets of each or is it better that your team first do review and make own action points? I think this is is great product but OOTB security had not been at priority list.

[zmstone]

We have to continue providing easy to start defaults.

• For security concerns of the default values, we will provide a security checklist (or alerts) (For internal ref: ER-246 )
• To simplify SSL listener configuration, we will implement ACME client (For internal ref: ER-247 )

[burner-]

I understand that there is always little balancing with easy deploy vs security. Anyway most of times it is also balancing so that it is better that product deploy take 10min instead of 5min if user prevent 5hour manual hardening work with it.
So it is much better to put admin/cluster listen ports to localhost by default and then document well how to open those. It is common practice in software industry by reason.
And for open listeners just enable password authentication by default and software wont get "my first student project" wibe at start.
Those are just bare minimum things to do if you have any kind security culture and wont make deployment any harder.