Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Then you have to choose one. See for a list of possible clients:
Not every client handles separate CSRs that well (for example, the recommended client certbotcan use a separate CSR, but isn't really build for it). I believe acme.sh can handle CSRs pretty well, but I don't have experience with it.
Let's Encrypt solely uses the ACME protocol to issue certificates (and uses CSRs in the communication between the ACME server and client), therefore you're required to use an ACME client.
Also note that Let's Encrypt certificates are only valid for 90 days and Let's Encrypt recommends to renew the certificate after 60 days. Therefore, Let's Encrypt is all about automation: set up your ACME client and services using the certificate and you shouldn't have to think about the renewing et cetera. However, using a separate CSR and requiring to manually import the certificate makes this rather difficult next to impossible. Things to think about.
Usually, one would install the ACME client on the same host as to where the hostname points to. I.e., in your case, the host with the IP address 129.152.32.94. This is useful when using the http-01 or tls-alpn-01 challenges. However, this is not required. It's perfectly possible to request the certificate from a different host and manage the challenge another way in the case of the http-01 or dns-01 challenges.
Note that Let's Encrypt requires proof of ownership for the hostname. See the link to the challenge types in the paragraph above.
The CSR shown has this Subject: Subject: C = Unknown, ST = Unknown, L = Unknown, O = Unknown, OU = Unknown, CN = "Strategic Pharmaceutical Solutions, Inc."
[which lacks a certifiable FQDN]
And no: X509v3 Subject Alternative Name:
So, there will be a problem with that CSR no matter which CA you take it to.
I think, in context, this Oracle guide is typically not expecting people to use a publicly-trusted CA like Let's Encrypt.
Forward the certificate file to your CA. Follow the process established by your organization.
In this case, I think typically "your CA" would be an internal organizational CA, rather than a publicly-trusted one.
At least the B2B use case described here doesn't really require the certificates to be publicly-trusted: they're expected to be consumed by a very small number of identified business partners, rather than by the general public.
And by using your own CA, you would overcome the need to renew the cert every 90 days.
[without automation you will eventually come to loathe the entire manual recertification process]