I see the same use case as #277 (comment). You might not have an (appropriate) email address or you might not want to give it to your ACME provider. You might not want to give up control of your account to your email provider. You might want to have distinct accounts for different domains not connected by any email address.

Currently, it encourages bad behavior for this use case. Let's Encrypt only accepts email addresses with domains on the Public Suffix List, so you are encouraged to make up something like absolutelydontdothis@no-email.com, $random@example.com, no-email@yourrealdomain.example, or invalid@0.0.0.0.in-addr.arpa (and you never have to verify any email address before issuing certificates), which is far worse for both Let's Encrypt and security than specifying no email address at all (and accepting that Let's Encrypt cannot contact you, e.g., when revoking certificates and that your account might be lost). You might also be encouraged to use other tools supporting registration without an email, like mentioned in #277 (comment).

From an implementation point of view, the current behavior (with userID: email,, // TODO: move to account struct? Currently MUST pass email.) feels more unpolished than (optionally) decoupling userID and email.

I do see your point, though, that people might get themselves into trouble and regret not specifying an email address later on but maybe a strong discouragement in --user-id's help text and forcing users to set an option with a deterring name (--i-accept-dangers-from-no-email-and-might-miss-crucial-information-about-my-certificates-and-my-account-might-be-lost) might work?

Uh oh!

register without email #277

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions