When generating SSL certs the user could have the option of clicking a create cert button which launches a script to run Let's Encrypt (open source free CA).
I proxy all HTTPS requests to CrushFTP via nginx. Nginx listens on the usual port 443 for HTTPS and directs all requests to the virtual host sub-domain, downloads.mydomain.something, to CrushFTP listening on 127.0.0.0 port 10443. The Let's Encrypt SSL certificate is installed in the usual manner for nginx.
That is a great workaround and I will probably do something similar.
I was just thinking how nice it would be if CrushFTP could carry out the SSL cert process for me.
A workaround implies that I'm giving something up. I think this is a superior solution to having CrushFTP listening directly on an external interface. To have CrushFTP listen for HTTPS requests, I either have to have it bind to port 443, which means that nothing else, like a web server, can bind to that port, or CrushFTP has to listen on a non-standard port. I don't like either option. The first option means that I'll have to dedicate a server just for ftp, which is a waste of resources. The second option leads to user confusion. Non-technical users don't do well with entering port numbers after the hostname. By proxying HTTPS requests via nginx, I have a clean implementation.
I don't see how CrushFTP "carrying out the SSL cert process" for you offers any advantage. SSL certificate creation and installation is really orthogonal to CrushFTP installation and configuration.
It look like it can probably be accomplished using the HTTP GET and POST functionality built into Crush. Unfortunately, I don't know enough about those requests to configure it.