I was told that you cannot use one tool to get a cert and another one to renew. But why? I thought the cert process is simply proving to a CA that you "own’ a website and then you send an encrypted request for a cert and it sends one to you. Basically.
Is there more to it that is client specific? For example, I ran openSSL to generate the keys and manually used the LE64.exe tool to get a cert. Then I had to use the Microsoft pkv2pfx.exe tool to convert it into a format that Microsoft wants (what a PITA to get that tool.) Then I manually installed it in the cert store and gave it a friendly name. Then I set up a binding for port 443 for both domain.com and www.domain.com, both using SNI, and applied the same cert to each. Finally, a URL Rewrite rule to forward non-SSL traffic to the SSL protocol since I had to leave a binding for port 80, and everything is great!
First question: why can’t I use Certify or lets-encrypt-win-simple to set up an auto-renewal for my site now that I already have a cert installed? Second question: does the old cert have to be removed from the cert store when it gets renewed or is it ok to keep expired certs in the store?
Just the representation of the obtained certificates and their status, which is apparently represented differently by each client, not standardized. (Maybe one is using a JSON file, one is using a sqlite file, and one is using keys in the Windows registry, or something?)
They are not using a Microsoft-provided standard about how to represent these certificates, and to my knowledge Microsoft didn't standardize this particular thing in a way that would be useful for Let's Encrypt clients.
If the client developers could agree on a standard for how to represent the certificate data, then the Windows clients could interoperate. There is no technical reason that inherently prevents this.
Basically with the clients it depends on whether those are specifically targeting certain environments or whether they are more “generic”. A client designed to be run specifically on Windows and produce certificates for IIS is likely to do “more” in terms of automating that specific bit of work. Generic clients are not necessarily to do as much in that case, but they are normally more portable and easy enough to automate anyway.
For example, ZeroSSL LE client is generic - it will accept all the same parameters and will produce exactly the same certificate files (in a commonly supported format) regardless of the platform. Say whether we run it on the Linux server with Apache or Nginx or on a Windows machine with those - there will be no actual difference in how it runs, how the data is stored and what results are produced.
Technically you can switch between clients rather easily, even if it might not always be possible for example to move from one way the data is stored to another - you can just generate a new certificate from scratch.
P.S. Having said all that I might add that it is a good point regarding pkv2pfx.exe, so I might add PKCS#12 (pfx) export to LE32/64 at some point.
P.P.S. Regarding OpenSSL - it is not necessary to use it to generate the keys (as LE client can do that for you). However, if you already had it installed, you could use it to convert the results to pfx (instead of pvk2pfx). See for example:
Ugh. Thanks for that info, it would’ve saved me a lot of hassle from finding & installing the SDK, copying out the pkv2pfx executable, then uninstalling the SDK.
If I generate a new cert using a different tool (e.g. lets-encrypt-win-simple) do I need to remove the old (existing) cert from the local store? Do I need to formally revoke it?
I don’t see why you’d need to revoke the existing one to be honest. As for the removing from the store - if the client is handling the certificate store for you, then you could just try running it in a “renew” mode probably.
Both of these clients will allow auto renewal. However these clients treat IIS as the source of truth (in Certifys’ case) and a custom File Structure in Lets-encrypt win-simple.
lets-encrypt-win-simple is based on the ACMESharp library which contains the information in a data structure called a vault.
In general with SSL there are no rules for either Windows or Linux on where certificates should be stored.
Linux clients like Windows clients vary in capabilities and how they deal with the information.
From an ACME protocol point of view the way the client interacts with the ACME server is defined, what the client does with the certificates is not, hence people write clients in a way that makes sense to them.