You don’t really need a CSR. You’re welcome to use one, but if you don’t have one already it’s not necessary, the software can conjure one anyway.
So, there are two separate elements, firstly you need to get Let’s Encrypt to issue you with certificates for the names you want (public Internet FQDNs for the FTPS server), then you need to configure ProFTPD to provide this certificate to clients when they connect.
Let’s Encrypt only issues certificates to subscribers who can prove they control the names they want on the certificate. You can prove this one of three ways, but for your scenario there are basically two approaches.
One, you could use Certbot’s standalone mode, in which it briefly acts as a web server. It needs for this server to be accessible from the Internet, using the name you want a certificate for, on either port 80 (HTTP) or port 443 (HTTPS). If you can’t or won’t allow access to these web ports from the Internet (after all this is an FTP server) then this is not an option.
If you can open up port 443 for certbot to use, you’ll want something like this to get example.com and ftp.example.com as the names of the server
certbot --standalone -d example.com -d ftp.example.com --standalone-supported-challenges tls-sni-01
If it’s easier with port 80 for whatever reason you need to ask for
certbot --standalone -d example.com -d ftp.example.com --standalone-supported-challenges http-01
Two, you could use the DNS-based clients, for which you need some way to change DNS entries related to the name you control from a program, e.g. via a web API or something. A popular client is https://github.com/Neilpang/acme.sh and they’ve got instructions on that site.