Don't do that.
First, OpenVPN own manuals suggest that it is not recommended to use a public CA. OpenVPN will trust any certificate which was published by that CA. I doubt you expect any holder of the certificate that was issued by the third party CA the to be able to connect to your VPN.
Second, there is no point in using public CA for private service. By the virtue of VPN, it is a private service which doesn't expect strangers to connect or trust your service. It has a valid and convenient root certificate distribution point — together with the VPN configuration file (probably, built into it), which you must distribute to clients anyway. Also it has a separate certificate store. All of this calls for a private VPN. So, there are no downsides of using private CA for VPN in comparison with, say, using it for public HTTPS, because you distribute the CA certificate. By the way, even HTTPS has a valid use for the private CA — in the same place as VPN, for client certificate validation; in that case you may still use public certificate for the server, but client certificates are signed with your private CA.
Third, Let's Encrypt issues domain validated certificates with TLS Web Server purpose. In correctly set up OpenVPN you only can install such certificate on the server. Client certificates must have reverse trait — TLS Web Client purpose. Let's Encrypt doesn't issue such certificates.
OpenVPN was designed with private, special CA in mind, purposed to this VPN only. They provide a set of scripts to create such a CA, it's called EasyRSA. It's really easy to use. If you don't want to use it (and you have a valid reason), you may use something else for creating this private CA, for instance, we once employed MS AD Certification Services for that.
