Customize the notAfter value

[timothyd09]

We are using a certificate vendor (Sectigo) that issues 365 day certificates via Acme by default. I have looked for an option to set the notAfter field to a specific value but it does not appear that is an option in win-acme. When working with others in my organization, they stated that it is possible via certbot (--certificate-validity-days 90) and acme.sh (--valid-to "+90d") to request a certificate that sets a custom expiration date xxx days in the future. I would like to have my certificates start expiring after 90 days so that it doesn't renew a certificate that is still valid for 275 more days and just sitting out there. I see in the Orders json file that the notAfter value is always set to null and it should be something that could configured. Please add an option to set the notAfter value either as a Settings option or per certificate (or ideally both) so that we can have the flexibility to modify the certificate's expiration date from the CA's default.

[WouterTinus]

Thanks for your feedback, I wasn't aware of this option and I'll probably add it to a future version of win-acme. In the mean time...

I would like to have my certificates start expiring after 90 days so that it doesn't renew a certificate that is still valid for 275 more days and just sitting out there.

...you could simply update your settings.json so that renewals happen less frequently.

[timothyd09]

Yes, we could use annual renewals, but we are actually trying to get ahead of proposed Google Chrome 90 day validity period and would like our certificates to actually expire at the 90 day mark. If this proposal passes, I am not sure if Sectigo will make the new default 90 days, but in either case, we would appreciate the ability to set the expiration date at the time of request. We are also working with Sectigo to determine what we can do to change the default value at request if win-acme isn't able to add this functionality. Much appreciated if you get add it in!

[WouterTinus]

A new config value is included in the 2.2.5 release

[timothyd09]

Thanks for adding that in so soon. I attempted to use it but I got the following error message.
Failed to create order: Fractional seconds are not supported

I attempted to figure out what Sectigo's requirements are, but I haven't been able to find anything definitive. Looking at the certificates that get generated when the "notAfter" value is set to null, the certificates are always generated with a notBefore value of the previous day @ 7:00:00 PM and the notAfter value is set @ 6:59:59 PM.

If possible, can you attempt rounding off the fractional seconds to see if that allows it to process? Thanks for your efforts on this!

Verbose Log
[VERB] Autofac: creating Execution scope with parent wacs
[VERB] Autofac: creating PluginBackend scope with parent Execution
[INFO] Plugin Manual generated source -redacted- with 2 identifiers
[VERB] Autofac: creating Split scope with parent PluginBackend
[VERB] Autofac: creating PluginBackend scope with parent Split
[INFO] Plugin Single created 1 order
[VERB] Checking -redacted-
[VERB] Autofac: creating Order scope with parent PluginBackend
[VERB] Autofac: creating PluginBackend scope with parent order-main
[DBUG] Reading certificate cache
[DBUG] No cache files found for renewal
[VERB] Order Main should run: True
[VERB] Obtain order details for Main
[VERB] No existing order found
[VERB] Creating order for identifiers: ["-redacted-", "-redacted-"] (notAfter: 09/06/2023 13:31:35)
[DBUG] [HTTP] Send POST to https://acme.sectigo.com/v2/InCommonRSAOV/newOrder
[VERB] [HTTP] Request content: {"protected":"-redacted-","payload":"-redacted-","signature":"-redacted-"}
[VERB] [HTTP] Request completed with status BadRequest
[VERB] [HTTP] Response content: {"type":"urn:ietf:params:acme:error:malformed","status":400,"detail":"Fractional seconds are not supported"}
[EROR] Failed to create order: Fractional seconds are not supported
[VERB] Order 1/1 (Main): error Unable to create order
[VERB] Processing order 1/1: Main

[timothyd09]

@WouterTinus - I'm following up on my previous comment to see if the new setting can round off fractional seconds to see if that works with Sectigo. Thanks!

[WouterTinus]

The latest release rounds to the nearest hour I believe, so you can give that a try. Forgot to mention it here in this thread, sorry.

[timothyd09]

Thanks for updating. I tested it again but unfortunately got the same result. Looking at the log, I see the following entry and it shows that it is rounding to the nearest hour. However, when cross-referencing this to the standard, I wonder if there are too many microsecond digits being passed or it is in the wrong format. Everything I'm reading seems to think that the format should be "2023-01-01T00:00:00Z" or "2023-01-01T00:00:00+04:00". This second format is what is used in the standard for new order posts. That is the only thing that stands out to me and I am in on way an expert on this technology. If that doesn't work, then I would likely need to work with Sectigo on why this is happening. Thanks again for working on this functionality!

[VRB] Creating order for identifiers: [-REDACTED-] (notAfter: "2023-10-19T21:00:00.0000000Z")

https://datatracker.ietf.org/doc/html/rfc8555 (reference the notAfter sections)

[timothyd09]

Also, looking up time formats, the period ( . ) indicates fractional seconds and is an optional value. The time zone value should have a colon ( : ) to delimit it. Hoping that if you can get it formatted without fractional seconds, that will solve the problem.

[webprofusion-chrisc]

If it helps for the win-acme implementation, in Certify The Web our notAfter is a DateTimeOffset which gets serialized as 2023-07-26T03:00:00+00:00, this seems to work well with all the CAs who seems to support notAfter in the orders so far, I don't have a sectigo account to test against. Google supports notAfter (also doesn't error on time), BuyPass accepts it in the order (if time is truncated) but ignores it, Let's Encrypt errors, pebble works.

  var notAfterDate = DateTime.UtcNow.AddDays(config.PreferredExpiryDays.Value);
  notAfter = new DateTimeOffset(notAfterDate.Year, notAfterDate.Month, notAfterDate.Day, notAfterDate.Hour, 0, 0, TimeSpan.Zero);

[WouterTinus]

So the original ACMESharp library code uses the format yyyy-MM-dd'T'HH:mm:ss.fffK and the comment says that's based on RFC3339. I'll just strip out the .fff (fractional seconds).

You can try the new build here in a few minutes: https://ci.appveyor.com/project/WouterTinus/win-acme-s8t9q/build/artifacts

[timothyd09]

Thanks for the update. I have tested it and it appears to be working as expected now. Thanks so much for your efforts!