Hi.
It looks like the default Value for the Certificate Lifetime is 90 Days in the App.
How can I Change this Value or how can I change the Application behavior to use the default Value of the CA an not the default Value of the App?
BR
Carlo
Hi.
It looks like the default Value for the Certificate Lifetime is 90 Days in the App.
How can I Change this Value or how can I change the Application behavior to use the default Value of the CA an not the default Value of the App?
BR
Carlo
The default certificate authority is Let’s Encrypt, and they have 90 day certificates. BuyPass have 180 day certificates but that’s pretty much the longest duration that the free CAs offer.
The app does not have a default lifetime value (the CA does), however you can specify a shorter than default value [for CAs that support it] under Certificate > Advanced.
Hi,
I installed the POSH-ACME Powershell Module since you used it for Certify. I tried to request a Certificate via the Powershell Modules and I get another Certificate with 90 Days Lifetime.
But as I used the New-PACertificate cmdlet with the -LifeTimeDays “365” parameter I got a valid Certificate with a 365 Days Lifetime.
If I use the field to specify a Lifetime in Certify and set it to 365 I get an Error like:
Fail to load resource from ‘https://acme.entrust.net/acme2/new-order’.
urn:ietf:params:acme:error:serverInternal: Unexpected server error.
Have you seen this before? Is Certify using this part of POSH-ACME to request a Certificate?
Hi,
Our app only uses some of the DNS providers from Posh-ACME, and for other ACME related operations we use GitHub - webprofusion/anvil: A client implementation for the Automated Certificate Management Environment (ACME) protocol
When you try to create an order with a specific lifetime the order gets the notAfter field set to the current date (UTC) + the number of days specified. Posh-ACME also sets the notBefore to current date (utc), which we don’t do, as that’s assumed, however that could make the difference with some CAs.
If they routinely issue certs with a date earlier than current time (as Let’s Encrypt also do,by 1 hr) then the default Cert start date + 365 could end up being 365 days and 1 hr, which might then exceed the max lifetime the CA issues for.
You could try requesting a cert for 364 days, or 364.95 (?) - we do support fractional days and we normalize that to the nearest hour (rounding down). What is the result with Posh-ACME if you request a cert for 366 days?
I would however expect the CA to raise a specific error instead of their issuance crashing, so it would be worth asking Entrust support if that could be the case (you could point them to this topic).
If you would like to debug the API calls to see the differences you could enable debug logging in Certify by editing C:\ProgramData\certify\serviceconfig.json and set LogLevel to “debug” - then restart the Certify background service and re-run your request. The app will log the https conversations with the API in C:\ProgramData\certify\logs\session*.log
If you can also enabled debug logging in Posh-ACME or use Fiddler to monitor the https conversation then we could go from there. We don’t have access to Entrust to do it ourselves.
Hi,
Thanks for your Input. I will have a look into your GitHub Link.
I still get a valid Certificate if I change the -LiftTimeDays parameter to 366.
Thanks for the hint to the API Debug log and Fiddler. I will give that a try.