search

dehydrated-io / dehydrated

letsencrypt/acme client implemented as a shell-script – just add water
https://dehydrated.io
MIT License
5.96k stars 716 forks source link

newOrder: support notAfter certificate validity #806

Open MEschenbacher opened 3 years ago

MEschenbacher commented 3 years ago

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?

lukas2511 commented 3 years ago

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.

MEschenbacher commented 3 years ago

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*
lukas2511 commented 3 years ago

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 3 years ago

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)