More of a conceptual question on fundamentals, since I don't really have a grasp on this curveball after doing renewals by rote for many years.
In doing my usual renewal (Crypt-LE v0.38, on Windows) I noticed that it was saying "Could not finalize an order" at the end and so wasn't creating the .cer file.
I soon found other threads on that, which led to the reason:
The answer was to let Crypt-LE generate a new CSR--the one I had been using was years old--at which point the .cer was produced as usual.
But getting it installed in IIS 10's Server Certificates is not working in the normal way, as doing the usual "Complete certificate request" there doesn't work (it seems to, but the new certificate vanishes as soon as you leave Server Certificates, which it absolutely never did before over many years). I'm assuming that's for a logical reason directly relating to using a new CSR, but I'm unsure.
In order to generate a CSR, you need a private key. When you originally let Windows/IIS generate the CSR, Windows took responsibility for generating and storing that private key and automatically associated it with the resulting certificate obtained by Crypt-LE when you imported it.
When you switched to letting Crypt-LE generate the CSR, it likely generated its own private key that Windows doesn't know about. At that point, you're no longer using the Windows certificate request process at all, so the "Complete certificate request" is unrelated to the Crypt-LE process.
I'm not really familiar with Crypt-LE specifically, but ultimately, the finalized certificate needs to be combined into a PFX file with the private key and imported into the Windows cert store so that IIS can see it and use it.
Alternatively, it should also be possible to keep using Windows to generate the CSR but change the settings so that it uses a SHA256 signature and doesn't get rejected.
Really it should be possible to just automate everything (and that's really how Let's Encrypt is intended to be used). Have you tried one of the other Windows clients that might integrate with your web server more easily?
@rmbolger Yes, that must be why, so I was on the right track by thinking in that direction, at least. It has been so long since I did this for the first time (i.e. not a renewal) that I didn't even recall where the original CSR came from, but it must have been IIS, which makes sense.
The PFX is what I would have done next, but that depends upon the certificate actually sticking in Server Certificates first, which it doesn't because of this core mistake.
I'll start over then with a fresh CSR generated from IIS. Well, as soon as I can -- I exceeded my certificate generation capability in troubleshooting this last night so apparently must wait until 2022-10-19T14:36:03Z.
BTW, what program is that screenshot from? That looks handy, whatever it is.
@petercooperjr Agreed! I'll look around, since it's a natural time.
That's just the Windows native certificate request dialog. It changes a bit depending on how exactly it was launched and whether you're in a domain with domain controlled cert policies.
But I'd echo @petercooperjr's suggestion of maybe looking into alternative Windows ACME clients that integrate more tightly with IIS such as Certify the Web.
You can troubleshoot against the staging ACME endpoint to get this working right now - you won't have the rate limits affect you. This way you should be good to issue against the production endpoint when your quota resets.
