Question: How to "onboard" existing certs and/or migrate from Certbot about posh-acme HOT 6 CLOSED

Hi @ppi-kosipenko. Yeah, it is easiest to start from a clean slate assuming your new certs don't run up against Let's Encrypt rate limits.

However, if you have any rate limit exceptions or feature flags associated with your ACME account, you'd want to import the account key into Posh-ACME so the they'll still apply to the Posh-ACME install. The New-PAAccount function has a -KeyFile parameter that can take a PEM formatted private key. The trouble is getting that key exported from certbot which I don't think it supports doing at the moment. I found a few certbot issues that reference folks wanting the feature to be added. One of them has a python script that will do the conversion for you.
certbot/certbot#3568

Looking a bit closer at how certbot stores its account key, it shouldn't actually be that hard to update Posh-ACME so it can directly import certbot's private_key.json which is in /etc/letsencrypt/accounts/<server>/directory/<guid>. I'll put that on my feature todo list.

from posh-acme.

Main concern is with certificates' expiration date. If I generate 10 new certificates today, they will all expire on the same date in the future. Current certs are staggered, so I am trying to find an elegant solution to stagger them moving forward without manually running the task to generate each certificate on different days of the week (ideally, weeks apart).

from posh-acme.

There's definitely no built-in way to migrate cert orders from certbot. I think both Posh-ACME and certbot store most of the order details as JSON, so it wouldn't be impossible to script a solution for someone determined to do it. It's just not really worth the effort to include in the module I think.

The least amount of effort would probably be to create fresh orders in Posh-ACME all at once...not even finalized certs, just a new pending order object with New-PAOrder. Then open the order.json for each one and tweak the RenewAfter value so it reflects the spacing you're looking for. That value represents the earliest UTC date/time that the module will try to renew the order (unless otherwise forced to). If "RenewAfter": null, or the field doesn't exist, the module will immediately try to renew/finish the order the next time Submit-Renewal is run against it.

from posh-acme.

Thank you! That should work.
What does 'expires' signifies and what will happen after that timestamp?

"CertExpires": "2023-06-12T18:53:37Z",
"RenewAfter": "2023-05-13T18:53:37Z",
"status": "valid",
"expires": "2023-03-21T19:51:28Z",

from posh-acme.

The expires field is part of the order object returned by the ACME CA and is separate and usually earlier than the expiration of the certificate associated with that order if there is one. What happens after that expiration depends on the ACME server implementation. Some CAs will purge the DB of the order object immediately and you won't be able to query for it anymore. Others will keep it around for a while and purge sometime later. Regardless of what the server does, the module won't try to query for the object anymore from the CA even if Get-PAOrder -Refresh is called.

For your purposes, creating a pending order and letting it expire shouldn't prevent the module from trying to renew it after the modified RenewAfter date. It will just use the local copy's data to create a new order when it's time to renew.

CertExpires and RenewAfter are appended to the local copy of the order object by the module based on the finalized certificate to make later decision making simpler to process.

from posh-acme.

thx again. closing...

from posh-acme.