Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

register without email #277

Open
streaps opened this issue Aug 23, 2016 · 18 comments · May be fixed by #1378 or #2060
Open

register without email #277

streaps opened this issue Aug 23, 2016 · 18 comments · May be fixed by #1378 or #2060

Comments

@streaps
Copy link

streaps commented Aug 23, 2016

Can lego register an account without an email address?

It is possible with other tools (letsencrypt.sh) and I don't have any need to share my email address with letsencrypt. see https://community.letsencrypt.org/t/email-address-disclosures-june-11-2016/17025

@mholt
Copy link
Contributor

mholt commented Aug 23, 2016

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

@hairyhenderson
Copy link

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

@mholt
Copy link
Contributor

mholt commented Mar 17, 2017

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

@hairyhenderson
Copy link

Thanks @mholt!

@xenolf
Copy link
Member

xenolf commented Mar 17, 2017

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.

@hairyhenderson
Copy link

@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.

@smtalk
Copy link

smtalk commented Jun 6, 2020

@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!

@smtalk
Copy link

smtalk commented Jun 18, 2020

@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.. :)

@rafaelgieschke rafaelgieschke linked a pull request Mar 25, 2021 that will close this issue
@rafaelgieschke
Copy link

rafaelgieschke commented Mar 25, 2021

I tried to implement this in #1378.

@ldez
Copy link
Member

ldez commented Mar 25, 2021

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.

@rafaelgieschke
Copy link

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 [email protected], [email protected], [email protected], or [email protected] (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?

@tisba
Copy link

tisba commented May 23, 2023

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.

@mholt
Copy link
Contributor

mholt commented May 23, 2023

@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.

@tisba
Copy link

tisba commented May 24, 2023

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.

@ldez
Copy link
Member

ldez commented Jun 21, 2023

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

@mcpherrinm
Copy link
Contributor

mcpherrinm commented Jun 21, 2023

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.

@ldez
Copy link
Member

ldez commented Jun 21, 2023

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.

@asyslinux
Copy link

.....I don’t understand why we can’t finally make this stinking --no-email flag? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
10 participants