Make it easier to renew multiple key-type certificates for a domain

[mrj]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.

How do you use lego?

Docker image

Effective version of lego

4.25.1

Detailed Description

To renew the certificates for a mail server that has both ec256 and rsa2048 versions, it seems I currently have to have my renewal shell script, looping for each key type, first move that type's files into the .lego/certificates directory, run lego, then move the updated files back to their separate directory.

A cert-dir option would make this unnecessary. Otherwise an option to add the key-type to the filename.

[ldez]

Related to #838

[n12c]

You can also have different --path for different types, then either accept having multiple accounts or symlink the same account key into both --path directories from somewhere else.

But, both of these are lame. acme.sh supports this workflow without contortions.

[ldez]

acme.sh supports this workflow without contortions.

I recommend avoiding this type of sentence: I call it "The Phantom Menace".

You don't have the historical context of lego.
You don't know the technical constraints or other use-cases.

So I want to be friendly, and I always try to find solutions, but sometimes maintaining an OSS feels like slavery.

My only incomes are donations: lego represents ~$20 per month avg.
I think I'm pretty active as a maintainer of lego, at least, more active than the time given to me by people with those $20 (thanks to them).

People come with demands or make passive/aggressive insinuations.

I already know the problem related to this issue; the solution is not trivial inside lego, but at some point, I will improve this part.

[mrj]

n12c, it seems that acme.sh puts the key algorithm in the cert filename. I'm not sure whether it always does this, or only when an algorithm is set on its command line. I used to do this manually for Lego using its --filename option. But that has now stopped working. Using --path to have a totally different configuration for each algorithm seems like overkill.

Ludovic, I'll likewise make one not-entirely-on-topic spiel:

Yes, n12c's comment was insensitive.

Although much of my work is only possible because of free software, I rarely donate to the open software projects I use. This is first because, as a developer with very limited resources, I'd feel like a chump because most wealthy users don't donate. I also don't want to encourage and reward the squeaky-wheel developers who nag the most (there's no implication about you here).

The solution I use for some of my open software is to just charge for it. The DevWheels Licence allows this to be done while keeping development fully publicly forkable. You can either have one low production-use charge for everyone, or set different rates for different classes of users. If the charge is affordable, libre is much more important than gratis.

The risk of moving from a FOSS licence to such a licence is that the package will be immediately forked, and the most popular one taken away from you. And some users will transfer to other functionally similar packages if they exist. Yes, forks to preserve the current licence will happen. But unlike non-FOSS licences which impose restrictions that users can't tolerate, DevWheels imposes none except an affordable charge. So there'd be much less social and financial pressure to support a fully-FOSS fork, and much sympathy for the OG devs, especially if the income helped fund many improvements.