Microsoft systems and the products of some Microsoft-dominated vendors (like HP and Brother) will not accept separate SSL keys and certficates. Instead, these need to be bundled together in PKCS12 format.
Converting PEM certificates to PKCS12 format is easily done with the openssl utility:
openssl pkcs12 -export -out _.example.com.pfx -inkey _.example.com.key -in _.example.com.crt
The name of the output file is specified after "-out". The original certificate key in PEM format is after "-inkey", while the original PEM cert is after "-in".
The utility will prompt for a password to secure the file, enter in something memorable to complete the operation (and make note of it in your Password Safe[1]. This password will be required when importing the .pfx file into vendor systems (e.g. HP printers).
The underscore dot domain notation is not mandatory, it's just how I now personally name wildcard certificates.
[1] You are using something like Password Safe to keep track of all your strong passwords, aren't you?
References:
Ivan Ristić, OpenSSL Cookbook.
Here's a mapping of the files I use:
The only device I use a pfx with is an older budget HP printer. The CA cert is uploaded separately from the pfx, as the pfx will fail to load if bundled with it. This particular device also can't digest the full chain cert (letsencrypt-chain.crt), but it will take the shorter chain cert (letsencryp-short.crt). If you have an app or device that specifies the CA has to be in the pfx, I think you'd need to first concatenate the server cert (cert.pem) with either fullchain.pem or chain.pem, and then bundle them with the private key using openssl. So something ilke this:
This will prompt for a password to set for access to the cert (which the app or device you're importing it into will request).
A quick test of the cert can be done using the following:
It should prompt you for whatever password you set when creating the pfx. If you don't get an ugly error message when you do that, your cert should be fine.
Whether you can bundle the CA certs, and if so what size (fullchain or chain) will depend on the app or device. I have found wide variation in how SSL is implemented over the years, so experimentation will be required if you don't luck out on the first try. The pfx specification does not prevent that. https://datatracker.ietf.org/doc/html/rfc7292.
Also, keep in mind that privkey.pem is usually created with perms that only allow the root or superuser to read it. To work on it you'll either have to use a privileged account or change the perms so your user can read it.
References:
"Understanding PFX File with Examples". How to Use Linux, https://www.howtouselinux.com/post/pfx-file-with-examples.
"pkcs" . openssl man pages, https://www.openssl.org/docs/man1.0.2/man1/pkcs12.html.
NOTE: The last example on the openssl man page for pkcs2 gives another variation on creating a pfx with additional certs: