From my reading of the documentation and personal testing, the renew command of the certbot client doesn’t work on certificates that have been issued with the --manual option. I’m wondering if this is intended to change in the future?
I understand that if the renew is basically asking for a new certificate with the same parameters it wouldn’t make sense since manual mode require to solve the challenge. But in the website of let’s encrypt, on the principle of certificate issuance (https://letsencrypt.org/how-it-works/#certificate-issuance-and-revocation) it says that the challenge has to be solved once, for the validation of the private key of a set of domain. Then for renewal the client just need to send a Certificate Signing Request to the let’s encrypt server. So in the end even for a manual certificate it shouldn’t be needed to solve the challenge again to renew a certificate? Is there something that I misunderstood in the renewal process?
That's correct. I'm not aware of any plans to change the behaviour of certbot renew, which is intended to run non-interactively, so naturally isn't really compatible with how the manual plugin works. I suppose it's possible that a interactive option for certbot renew will be added in the future, which would save you the trouble of figuring out what the exact command was to get the certificate and re-running that.
What's missing from this picture is that domain authorizations (which is the result of a solved challenge) are only valid for a certain period of time. Right now, that period would actually allow you to issue multiple certificates (I think it's 10 months?), but this is going to change within the next couple of weeks to 3 months, and will be lowered even further in the future, so it's not really something you can rely on for the manual plugin. Either way, no matter how long the expiration period is, as long as domain authorizations are not valid forever (which would be bad, given that domains change ownership all the time), it wouldn't be something you could rely on permanently.
Additionally, certbot and many other clients do not reuse existing domain authorizations anyway, i.e. they request a new challenge every time, so even if this were an option, the clients currently don't make use of it.
[quote="pfg, post:2, topic:18305"]
What's missing from this picture is that domain authorizations (which is the result of a solved challenge) are only valid for a certain period of time.
[/quote]The specs has following paragraph:
The server SHOULD issue the requested certificate and update the application resource with a URL for the certificate as soon as the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MAY proactively issue the requested certificate and provide a URL for it in the "certificate" field of the application. The server MUST, however, still list the satisfied requirements in the "requirements" array, with the state "valid".
If I’m reading it right:
If you try to renew cert (i.e. get new cert for same csr) right away, using ANY plugin, server won’t ask for authorization, because you did it few min ago.
The diagram in Resources paragraph shows same thing.
That’s the latest draft, released a couple of weeks ago. The relevant one for Let’s Encrypt today would be the acme-01 draft.
Additionally, renewal is not something you typically do minutes after first getting the certificate, so when you’re actually renewing a certificate, expiration will become a problem. And even in the latest draft, there’s still an expiration time built in:
expires (optional, string): The timestamp after which the server
will consider this application invalid, encoded in the format
specified in RFC 3339 [RFC3339]. This field is REQUIRED for
objects with "pending" or "valid" in the status field.
[quote=“pfg, post:4, topic:18305”]
That’s the latest draft, released a couple of weeks ago. The relevant one for Let’s Encrypt today would be the acme-01 draft.
[/quote]Ok. Is it available for use or testing already?
Is there a certbot (beta?) matching latest draft?
[quote=“pfg, post:4, topic:18305”]
Additionally, renewal is not something you typically do minutes after first getting the certificate[/quote]I meant it as a way to test renewal process only, nothing else.
I’m not aware of any client or server implementations that implement anything other than acme-01 (possibly with some backwards-compatible changes from later drafts).
[quote=“pfg, post:6, topic:18305, full:true”]
I’m not aware of any client or server implementations that implement anything other than acme-01[/quote]Ok. How do we monitor latest draft state? Is there “milestones” thread for it?
The protocol is developed by the IETF, like many other internet protocols. Getting involved on the mailing list is the best way to keep track of changes. See the ACME WG page for more details.
Let’s Encrypt’s policy for adopting new versions of ACME is documented here.
