Lego: Certificate expiration date later than subCA expiration date

[sebastien-baillet]

We use step-ca as ACME server, and we had an issue due to a late subCA renewal. Just before the date of the renewal, the ACME server issue certificates with expiration date later than subCA expiration date. As lego doesn't renew certificate that expires in more than 30 days by default), we had a period of time where the certificate became invalid due to the subCA expiration date.

I opened an issue in step-ca repository too.

How such case should be handled? Maybe lego can log some warning when this case happens?

[dmke]

A warning should certainly be issued, usually lego is run in a cron job (or nowadays more likely a systemd timer). Not sure how visible this is.

I wonder however whether this isn't a spec violation (if not, it definitively violates my expectations). In this case, lego should abort with an error ("faulty CA") and not even store the new cert/key material.

Your thoughts, @ldez?

[ldez]

FYI, the main usage of lego is as a library :wink:

I'm not sure, as an ACME client, we have to check this kind of element related to the CA.
From my point of view, the ACME server has to be able to deliver certificates that follow the CA constraints.
I think that is a chain of trust: we have to be able to trust the ACME server on that point.

If we cannot trust the ACME server, we will have to validate more things that just the NotAfter property.
But those validations will consume resources for things that are not useful in the majority of the ACME server implementation.

[dmke]

FYI, the main usage of lego is as a library :wink:

Then the host application is either run in a cron-like manner (or in case of sth. like Træfik, which schedules lego code to run at a certain interval). The point I'm trying to make is, that the user might not see a warning.

From my point of view, the ACME server has to be able to deliver certificates that follow the CA constraints.
I think that is a chain of trust: we have to be able to trust the ACME server on that point.

I agree. I see step-ca as the culprit here: It should not issue such a certificate.

(Side note: do we know how Let's Encrypt handles this? I'd guess they'll have a new intermediate ready long before the old expires.)

I'm not sure, as an ACME client, we have to check this kind of element related to the CA.
[...]
If we cannot trust the ACME server, we will have to validate more things that just the NotAfter property.

In the end, it's all about edge cases, and how we handle them. I'd argue that leaving the user with an invalid certificate is unacceptable.

Let's see which steps the step-ca takes.

[sebastien-baillet]

After some thought, I don't think something has to be done on lego:

• Since there is nothing in RFC about this case, we need to avoid different ACME clients behaving in different ways,
• Since only the owner of the CA can correct the problem, I prefer a notification server side.

I will close the issue in a week or so, if nobody has new argument.

[dmke]

It looks like step-ca has formulated a plan of action, so I'm going to close this for now.

@sebastien-baillet: Please feel free to re-open this issue, if you think we still need to do something within Lego.