support custom certificate collections (suppressing SAN merging)

[thewilli]

Currently, an issued certificate and its related files are stored in ~/.acme.sh/<CN>. This works great for most cases, but prevents one from creating different certificate sets with the same common name.

• a web server might get wildcard certificates, e.g. example.com being the CN and *.exmple.com part of the SANs
• for legacy systems that do not support SNI a certificate containing all domain names used as SANs might be required
• a mailserver is not required to get a wildcard certificate, but might require a certificate containing several domain names as SANs

All of these scenarios listed above could generate a certificate with example.com as common name, but - intentionally - differ in SAN entries.

I would propose to stick to the current behavior by default, but allow to pass an identifier which would act as directory name below ~/.acme.sh/ and suppress the default SAN-merging mechanism. Even if not depending on the directory name, it could be combined with --install-cert as well.

# ~/.acme.sh/example.com
acme.sh --issue -d example.com -d foo.example.com
# ~/.acme.sh/example.com
acme.sh --issue -d example.com -d foo.example.com -d bar.example.com
# ~/.acme.sh/myspecialcert.custom
acme.sh --issue -d example.com -d baz.example.com --custom-id myspecialcert

It would be quite easy to modify the search mechanism so listing and renewing certificates does not depend on the directory name any longer.

What do you think?

What you accept such a PR?

[FernandoMiguel]

My understanding is that COMMON NAME is being deprecated, correct?

[FernandoMiguel]

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/

[FernandoMiguel]

@thewilli you can use --config-home and set each of those configs in a diff location

[thewilli]

@FernandoMiguel

My understanding is that COMMON NAME is being deprecated, correct?

as the CN gets added to the SANs it doesn't matter at all

you can use --config-home and set each of those configs in a diff location

yes, but that would create an additional overhead, I couldn't list my certificates any longer using the plain --list option and for sure the cronjob wouldn't work as expected.

All I want is to use acme.sh to issue certificates with an overlapping set of SANs, and I'm sure others might find this useful as well.

[gringus]

Another use case would be certificates with OCSP Must Staple (eg. for nginx) vs without (eg. dovecot, postfix do not support OCSP at all). As was mentioned above: having separate configuration is acceptable, but it would be nice if all certs are in the very same place. Having something generic would allow to potentially get rid of eg _ecc suffix exception.