Private keys
ACME is all about automation and certificates are typically considered to be disposable and easily replacable. There are scenarios though where you want to manually handle a certificate and its private key.
Always-accessible private keys
The best way to access the private keys is to configure your renewals to save the certificate in an easily transferrable way, e.g. by using the PFX file store plugin.
If you’re using
the default Windows Certificate Store
plugin you can set PrivateKeyExportable to true to enable certificates to be exported with their keys included. The best tools for exporting are Powershell and the “Manage Computer Certificates” MMC snap-in, because when UseNextGenerationCryptoApi is enabled, even exportable certificates cannot be exported by the IIS Manager.
Disaster recovery
The PrivateKeyExportable setting only works for future certificates,
so if you’re in a hurry you can force the renewals using ‑‑renew ‑‑force
or from the interactive menu to get new certificates with exportable keys.
When renewal is not an option and you need to get the current certificate,
you can find a .pfx file in the {Client.CertificatePath}. You can access the
passwords for these cache files from the main menu (Manage Renewals > Show details)
or you can decrypt the .renewal.json files and
subsequently find the passwords in plain text.
Reuse private keys
If you don’t want your private key to change for each renewal, you can use the option
‑‑reuse-privatekey when setting up the renewal. This can
Private key cache
By default simple-acme retains a copy of the private key in its certificate cache. These files are both encrypted and protected by access control lists in the file system. You can disable this feature by setting Cache.ReuseDays to 0 There will still be .pfx files written to disk containing the certificates (this is used for various other purposes, like detecting source changes, revokation, etc.), but they will not contain any private key information.
Arguments
‑‑reuse-privatekey |
Reuse the same private key for each renewal. |
|---|
Settings
Cache.Path |
The path where certificates, request files and private keys are cached. If you are using CentralSsl, this can not be set to the same path.
Paths should be JSON-encoded, e.g. Default: undefined (defaults to {Client.ConfigurationPath}\Certificates.)
|
|
|---|---|---|
Cache.ReuseDays |
When renewing or re-creating a previously requested certificate that has the exact same set of domain names, the program will used a cached version for this many days, to prevent users from running into rate limits while experimenting. Set this to a high value if you regularly re-request the same certificates, e.g. for a Continuous Deployment scenario.
Setting this to 0 will not entirely disable the cache (the program also needs the files for different reasons), but it will prevent the files from being used for renewals and will also ensure that no private key material is stored in the cache, unless specifically requested by ‑‑reuse-privatekey.
Type: number Default: 1
|
|
Store.CertificateStore.PrivateKeyExportable |
If set to true, private keys stored in the Windows Certificate Store will be marked as exportable, allowing you to transfer them to other computers.
Note that this setting doesn't apply retroactively but only to certificates issued from the moment that setting has changed. For tips about migration please refer to this page. Default: false
|
|
Store.CertificateStore.UseNextGenerationCryptoApi |
If set to true, the program will use the Cryptography API: Next Generation (CNG) to handle private keys, instead of the legacy CryptoAPI.
Note that enabling this option may make the certificates unusable or behave differently in subtle ways for software that only supports or assumes the key to exist in CryptoAPI. For example:
Default: false
|
Looking for win-acme?
simple-acme is a backwards compatible, drop-in replacement built by the same person. Project history.