Based on @ahaw021 link, you will be able to create a CSR (Certificate Signing Request) from the device, and you can use the Certbot software (or some other Let’s Encrypt clients) to submit this CSR to Let’s Encrypt. The CSR embodies a list of one or more FQDNs (Fully Qualified Domain Names) for which a certificate is requested, plus the device’s public key which will also be baked into the certificate, plus proof that the device has the private key corresponding to that public key. Certbot (or the other software you choose) will have specific documentation about how to use it when you have a CSR already, which you should read. If the software you want to use doesn’t say anything about how to present a CSR that you already have, it probably can’t be used in your scenario.
The only thing Let’s Encrypt needs besides this is proof that you really control the FQDN mentioned. This proof can be via control over a web server accessible on that FQDN, or through DNS TXT records.
However, because the Palo Alto Networks device needs manual steps during this process, and Let’s Encrypt certificates last only 90 days before expiring, you may decide that it makes more sense to choose a traditional commercial CA in order that you only need to renew certificates every year or two. If you decide that Let’s Encrypt would have suited your purposes except that the product’s manual renewal steps were a problem I encourage you to mention this to product vendors when you’re next in the market for a device that can use SSL certificates. On the other hand, tasks done every 8-10 weeks do have the advantage that somebody will probably document them and train their replacement how to do them. We do see situations where a company buys a two year certificate for something and then two years later nobody in the company knows how to replace it, and they get in a pickle.