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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: tst2public.serviceconnect.defence.gov.au
I ran this command: certbot certonly --manual --csr "C:\Program Files\Microsoft\jdk-17.0.12.7-hotspot\bin\tst2publicserviceconnectdefencegovau.csr" --preferred-challenges "dns"
It produced this output:
An unexpected error occurred:
No order for ID 314377489407
My web server is (include version): Apache 9.0
The operating system my web server runs on is (include version): Windows server 2022
My hosting provider, if applicable, is:n/a
I can login to a root shell on my machine (yes or no, or I don't know): n/a
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.8.0
Certbot on Windows, with a specified CSR file, is almost certainly the hardest way of accomplishing what you're trying to do. The certbot team no longer supports Windows, and using a manual authentication with CSR will prevent automation. You probably want to use one of the clients designed for Windows, like Certify the Web or win-acme, to automatically configure your Apache-on-Windows installation and be able to renew automatically.
In terms of your actual error message, that's a pretty unusual one. It may be just a one-off fluke, which their staff calls "the 404 bug" of their replicas not being as synchronized as they're supposed to be. (And they had some challenges with keeping up with their load recently; I don't know if that might be related.) I'd suggest just trying again, and seeing if it recurs.
An unexpected error occurred:
No order for ID 314377489407
Unfortunately, sometimes Let's Encrypt erroneously returns a 404 error if there's a bit of database replication lag between our primary and replica databases. This is something we're working on, but is unfortunately a bit of a pretty deeply-rooted problem in how we currently scale to meet our load needs.
You should simply try again and it will likely succeed.
I haven't used Certify the Web myself, but I think you're looking for their documentation on Deployment Tasks which let you deploy the certificates that it manages to whatever systems you need to deploy them too. The developer @webprofusion hangs out here and may be able to give you more specific guidance if you have more specific questions.
Certify will natively generate a PFX and store it in the local machine store by default, but it's auto deployment is optimised for IIS (not apache etc).
For users who are deploying to IIS (which most windows based web servers use) they don't need a deployment task, but for further conversion for other services or if you want to export the certificate to a custom location you do need a deployment task.
On Windows certificates are typically used directly from the OS certificate store, but cross platform apps tend to use files directly from the filesystem instead. Whether they require PFX or PEM file etc depends on the how the particular service is built.