newOrder: support notAfter certificate validity #520

New Issue

2025-12-29T01:26:43+01:00

adam commented

2025-12-29 01:26:43 +01:00

Originally created by @MEschenbacher on GitHub (Mar 7, 2021).

The ACME protocol supports requesting certificates with a certain validity as optional notAfter field in the call to the newOrder resource: https://tools.ietf.org/html/rfc8555#section-7.4. If unspecified, the issuing CA will decide on the validity.

I've been playing around with a private PKI (step-ca) and I'd like to issue shorter certificates if the clients choose to.

Do you think we should add support for this?

Originally created by @MEschenbacher on GitHub (Mar 7, 2021). The ACME protocol supports requesting certificates with a certain validity as optional `notAfter` field in the call to the `newOrder` resource: https://tools.ietf.org/html/rfc8555#section-7.4. If unspecified, the issuing CA will decide on the validity. I've been playing around with a private PKI (step-ca) and I'd like to issue shorter certificates if the clients choose to. Do you think we should add support for this?

adam commented

2025-12-29 01:26:43 +01:00

@lukas2511 commented on GitHub (Mar 21, 2021):

Sure, sounds good. At least notAfter should be easy to implement. notBefore would probably require some restructuring in how cert files are stored so I'd rather avoid that one for now.

@lukas2511 commented on GitHub (Mar 21, 2021): Sure, sounds good. At least `notAfter` should be easy to implement. `notBefore` would probably require some restructuring in how cert files are stored so I'd rather avoid that one for now.

adam commented

2025-12-29 01:26:43 +01:00

@MEschenbacher commented on GitHub (Jun 26, 2021):

I'm currently taking a stab at implementing this and I'm struggling to find a portable way of generating the RFC3339 timestamp required as notAfter.

Depending on the solution to the portable timestamp generation, I can think of the following configuration options:

# request the validity in day granularity
CERT_DAYS=7
CERT_DAYS=$((3 * 30))

# request the validity in hour granularity
CERT_HOURS=$((60 * 24))
CERT_HOURS=1440

# supply a date(1) parseable string
CERT_VALIDITY="10 days"
CERT_VALIDITY="30 minutes*

@MEschenbacher commented on GitHub (Jun 26, 2021): I'm currently taking a stab at implementing this and I'm struggling to find a portable way of generating the RFC3339 timestamp required as `notAfter`. Depending on the solution to the portable timestamp generation, I can think of the following configuration options: ``` # request the validity in day granularity CERT_DAYS=7 CERT_DAYS=$((3 * 30)) # request the validity in hour granularity CERT_HOURS=$((60 * 24)) CERT_HOURS=1440 # supply a date(1) parseable string CERT_VALIDITY="10 days" CERT_VALIDITY="30 minutes* ```

adam commented

2025-12-29 01:26:44 +01:00

@lukas2511 commented on GitHub (Jun 26, 2021):

I think having it defined in days or hours would be the way to go. Way less parsing necessary and I don't really see the point to have validity to an exact minute. Personally I think having just days defined should be more than good enough.

@lukas2511 commented on GitHub (Jun 26, 2021): I think having it defined in days or hours would be the way to go. Way less parsing necessary and I don't really see the point to have validity to an exact minute. Personally I think having just days defined should be more than good enough.

adam commented

2025-12-29 01:26:44 +01:00

@lukas2511 commented on GitHub (Jun 26, 2021):

Would be quite nice to have an error if the selected time span isn't possible (e.g. being higher than max age by the CA, or something weird like being <= 0)

@lukas2511 commented on GitHub (Jun 26, 2021): Would be quite nice to have an error if the selected time span isn't possible (e.g. being higher than max age by the CA, or something weird like being <= 0)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#520