The underlying acme package can, but the command doesn't currently allow that.

@mholt is there any reason why lego shouldn't allow registering without an e-mail address?

Other than it being strongly, strongly discouraged? Not that I know of, no. @xenolf would know better though.

Thanks @mholt!

Yeah like @mholt said, there is no other reason then it being discouraged. I'm not sure why you would like to specifically not have a recoverable account.

@xenolf It's not a strong use-case, to be clear - more of a vague idea. My main use-case is for developers who set up temporary sites that usually live for 2-3 days (7 tops), and it'd be slightly inconvenient for them to have to specify an e-mail address when there's never really a need to renew. Right now that scenario involves self-signed certificates, which are increasingly annoying to deal with.

Mostly I'm not 100% clear on exactly what LE/ACME does with the e-mail address - I'll do some more reading and figure it out.

@hairyhenderson similar needs here, we just don't know real email addresses on the systems we're auto-deploying the certs. On the ones we 'known' them - some certs are just temporary ones or different sets, and they get flooded with expiring certificate notices then (they're confusing, as they include a different set of SANs). Having ability not to specify the email would be really great!

@ldez just wondering if there is a chance to see this included into the next release? We'd replace our own LE client with lego on all the installations of DirectAdmin, that's the only thing left.. :)

I tried to implement this in #1378.

I don't really understand the need:

• if you are a company, it's highly recommended to use an email, like that if you have a rate limit problem Let's Encrypt will be able to increase your limit for this email
• you can use an email alias to catch all those emails, and "hide" them
• Let's Encrypt discouraged to do that

I don't want to change the current default behavior, that promotes the use of an email like Let's Encrypt recommends, without a strong use case.

For now, I don't see any strong use cases but if you have one, please share it.

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?

Just found this issue as I was wondering why lego requires an email. I'm genuinely interested in understanding and not trying to offend anyone.

@xenolf said

Yeah like @mholt said, there is no other reason then it being discouraged. I'm not sure why you would like to specifically not have a recoverable account.

That might be relevant for some, but certainly not for the majority. Unless I'm overlooking something, the email is only used for

1. expiration email (as a hobbyist I don't care, as a professional I have monitoring)
2. certificate revocation (you can always do that if you can prove control)
3. General communication from Let's Encrypt, security infos etc (IMO, same argument as with 1.)
4. rate limits

Only rate limits might be a reason to have a "fixed" and "recoverable" account, so that you can request an override if you are a large provider.

I don't quite follow what else could be meant by "recoverable account" and why Let's Encrypt discourages to leave out the mail. Do you have a reference for that, @ldez? (#277 (comment)). I can't find anything in that regard in the Let's Encrypt documentation, nor in EFF's certbot docs. AFAIK certbot is the de-facto recommended tool and is quite clearly communicating email to be optional.

@tisba

That might be relevant for some, but certainly not for the majority. Unless I'm overlooking something, the email is only used for

• expiration email (as a hobbyist I don't care, as a professional I have monitoring)
• certificate revocation (you can always do that if you can prove control)
• General communication from Let's Encrypt, security infos etc (IMO, same argument as with 1.)
• rate limits

Only rate limits might be a reason to have a "fixed" and "recoverable" account, so that you can request an override if you are a large provider.

I don't quite follow what else could be meant by "recoverable account" and why Let's Encrypt discourages to leave out the mail.

Please notice that this issue was opened 7 years ago, well before the current ACME standard.

At the time, the ACME draft had this language:

Once a client has created an account with an ACME server, it is
possible that the private key for the account will be lost. The
recovery contacts included in the registration allows the client to
recover from this situation, as long as it still has access to these
contacts.

Thank you, that was the missing piece.

From your comment I take that by know it would indeed be acceptable to make email optional for lego? If that's the case, I'd take a look if I can contribute a PR to change this requirement.

@mcpherrinm maybe you can provide more context from the Let's Encrypt point of view on this topic?

It should be possible to register without an email, because otherwise people will put in bogus values, which helps nobody and causes us to send emails into the void.

It is, however, still valuable for most people to provide an email for communication about their certificates, so an explicit opt-out flag (like --no-email) is IMO the best approach.

otherwise people will put in bogus values, which helps nobody and causes us to send emails into the void.

ok, this argument is strong enough for me, so @mcpherrinm you can open a PR.