Lego: --filename depreciation

[lenovouser]

I just saw in the readme that it is intended to depreciate the --filename option. I currently use this for two reasons:

• I generate the exact same certificate twice, one ecdsa and one rsa version.
• I generate other certificates which have the same commonName / first SAN entry

I think lego currently bases it's filename on the commonName / first SAN entry (at least it was done that way around the time the --filename option was added)

which is why the certificate I did generate first - ecdsa for example - would be overwritten by the one that was generated last (rsa) or in the 2nd case by a completely different certificate.

I didn't see an explanation yet as to why is it intended to remove that option, and is there an alternative I could use when it happens 😰?

[ldez]

--filename is deprecated because the option is not consistent between read and write certificates.
This cause an issue on the renew.

I think that I merged the PR https://github.com/go-acme/lego/pull/612 too quickly, at that moment I had not seen the problem.

I think that the --filename is not the good way to manage your use-cases: I would prefer that lego learn to create better certificate filenames by default.

I generate the exact same certificate twice, one ecdsa and one rsa version.

Out of curiosity, why do you need to do that?

I generate other certificates which have the same commonName / first SAN entry

I don't understand this use-case, could you give me more explanations?

[lenovouser]

I think that the --filename is not the good way to manage your use-cases: I would prefer that lego learn to create better certificate filenames by default.

True, even though I can't think of a good way to auto-generate the name. An option would be to maybe switch to only user-supplied names (which would also be required on renew, thus it could resolve the location on the filesystem), but that would add another option that's required even though most basic users won't need it. So not the best idea, even though a solution I suppose.

Out of curiosity, why do you need to do that?

Some reverse proxies like NGINX support supplying an ecdsa and a rsa certificate and choose the one that's supported by the client automatically based on the signature_algorithms extension in the TLS handshake. We use it for some sites that have a lot of clients on older machines with browser versions that don't support ecdsa yet or other software that doesn't.

I don't understand this use-case, could you give me more explanations?

I don't remember why exactly, but we have some different certificates with the same commonName / first SAN entry but otherwise different SAN entries - I'd have to take a look as to why. I think it had something to do with the LE limit on the amount of SAN entries per certificate or something along those lines. Not my biggest issue though as I can imagine being able to get rid of that, my biggest problem is rsa and ecdsa overwriting each other.

Would it be possible in theory to make renew just also make use of the --filename parameter in case it is specified, and print a hint along the lines of

You should supply --filename in case you used it to request the certificate the first time

if --filename isn't specified and lego doesn't find the certificates on the filesystem?

[znerol]

Certhub is using --filename parameter in combination with --csr. In that project lego is only used as a stateless acme client (certificates are kept in git repo, expiration checks and certificate renewal is managed either via systemd units or ci pipelines). Hence the only lego command relevant there is run. Our use case would be covered with a --stdout flag (fullchain written to stdout).

[equinox0815]

@Idez why don't you add all domains of the certificate to the json file. This way renew only needs the filename argument to find out what other domains should be part of the certificate.

[lenovouser]

@znerol's idea with a --stdout flag would probably also cover my needs 👍🏻