I am currently replacing Exchange 2013 on Server 2012 with Exchange 2019 on Server 2022 core. The old Exchange is still productive, it has been renewing its LE certificate automatically via HTTP challenge for years. I have already set up the new Exchange with exactly the same mail domains (the old Exchange is offline during setup). On the new system I created a certificate with the Win-Acme client (wacs.exe) in exactly the same way as on the old system. Now there are several problems:
the certificate is visible in the EAC on the new server, but not in the IIS management console
i cannot assign an SMTP service to the new certificate, neither in EAC nor in EMS (the IIS service assignment works); no error message
the certificate is visible in the MMC of the new server, but it says "Private key not found".
the attempt to export the certificate and the key on the old server and import it on the new server in the MMC does not work. It says: "The private key is not marked as exportable".
Could someone please outline the steps to create or migrate an LE certificate to a new system with the exact same domains?
Any help will be greatly appreciated,
Stefano
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:kgb.koeln
I ran this command: win-acme client
It produced this output: new certificate
My web server is (include version): IIS / Exchange 2019
The operating system my web server runs on is (include version): Server Core 2022
My hosting provider, if applicable, is: -
I can login to a root shell on my machine (yes or no, or I don't know): yes
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): -
No ACME client (including wacs.exe) will create a new cert without a key.
So, I have no idea what is going on there.
I prefer to use CertifyTheWeb on Windows systems.
[and I've had no problems with it whatsoever]
So, there must be a private key there [somewhere].
I suppose the script that [tries to] puts it into the key store is malfunctioning.
Is that the latest version of wacs?
That's something that's set when the cert is stored and once it's set you can't undo that without re-importing the same cert (for win-acme that probably means re-requesting the same cert)
Hi guys, another try, still struggling with this problem (win-acme running on second server, but does not install private key).
In the meantime, I have found a few statements that indicate that the private key is only generated (once) on the original system. If win-acme is used on a second server (with the same domains), the private key should/must be copied manually from the first system to the second system. Can someone briefly tell me where I have to copy the private key so that win-acme can link it to the certificate?
A private key is a secret generated at the time you are about to make a certificate signing request to the certificate authority. It is used to generate a corresponding public key and that is what your certificate issued by the CA is associated with. For many/most ACME clients the private key is generated for every certificate renewal and not reused.
On windows when an app like win-acme stores a certificate in the local machine certificate store it normally does so using a PFX file (also called a p12 archive) which is an archive containing your public certificate, the public intermediates CA certificates used to issue your cert, and your private key), windows then splits that file into the public certificate and the private key and stores all those parts seperately. Certs are imported as registry entries and keys are stored (encrypted) on disk under C:\ProgramData\Microsoft\Crypto (with the specific destination varying by key type and cryptographic service provider).
When an imported key is marked as non-exportable it really is designed so that you can't easily export it (more accurately, decrypting it). If you have the source PFX though (and know the password if there is one) then you can just import it on the new machine and that will store the private key as well.
win-acme will also keep a copy of the original PFX somewhere under C:\ProgramData\win-acme,normally using the PFX directly is the easiest way to move a cert between machines on Windows, because you know it has the private key. The trick though is if the key has a password (which win-acme stores encrypted): win-acme
There is no need to copy private keys from one machine to another if you can instead generate a new certificate on that machine. I would advise completely ignoring the private key issue, instead issue another certificate on the new server, manually set it up in Exchange etc so that you know all the features are configured, then worry about renewals (running your script on renewal).
If you are fighting with HTTP validation to get a certificate issued consider using DNS validation instead.
Oh, and keep in mind that the private key (when imported) is stored on disk, which means it has permissions, which means there is complexity around which user was running the process that imported the key. If your software/service cannot access a private key it usually mean it's doesn't have read permission on the key, not that the key doesn't exist.
First of all, thank you so much for this detailed information. What is actually new for me is that a new private key is generated every time a certificate is generated and/or renewed. This makes it clear that the PK must exist on the new server and that it is simply not seen by MMC/IIS/Exchange. Then I must actually have a permissions problem. Perhaps something has changed in the rights management between Server 2012 and Server 2022 - I have never worked with an elevated prompt on the old server. I will start the Wacs on the new core with elevated rights at the next opportunity.
Ok, in the end you were right to ignore the private key thing. After running Wacs on the new server and testing OWA, ActiveSync and receiving email via SMTP, it turns out that everything works - EVEN though the certificate management says there is no private key and even though the EAC won't bind the SMTP service to the certificate. So in the end, I guess it's that the remote tools used to manage Exchange on the core server just don't show the same as management tools running directly on the server. Well, that cost me a lot of time.
As an aside, IIS has a feature called CCS (Centralized Certificate Store) and it's UI often shows a broken private key as well. A lot of certificate tools date from before automated certificate updates, so they were expected to be manually installed by an administrator once a year at most, which in turn has side effects on the associated permissions and usability.