Clarify the --email flag requirements?

When running webroot authentication I have been passing the --email flag every time. Is this required everytime or only for 1st time only ?

Does it have to be the same email address every time ? If it’s same email address every time, I am thinking for my automation i can just populate the email address in cli.ini instead https://letsencrypt.readthedocs.org/en/latest/using.html#configuration-file ?

1 Like

any ideas @schoen @kelunik @rugk ?

I’ve not used the flag yet, maybe I should. Will try it tomorrow. I guess it’s enough during the first time from what I remember from the docs, because it’s a different command to register than to issue a new certificate.

1 Like

Good question @eva2000. I created #1310 in response to this post.

The answer is --email is only used when creating an account with the ACME server which is one of the first things the client does. Once you’ve had a successful run with letsencrypt and this account has been created, the --email flag has no effect. Since it does need to be specified the first time the client is run, putting it in cli.ini sounds like a good idea to me.

2 Likes

thanks @bmw will follow the created issue thread

AFAIK the email is not required. It’s just that LE can send you notifications and so on if you specify it…

I already mentioned the mail issue in this topic and it is quite important there if you want to notice LE users of a major change or security issue.

1 Like

@bmw what about updating or changing the registered email address ?

for example, if the end user typed in wrong email address or incorrect one, how do they update it ?

working on my letsencrypt integration and dealing with email address so far https://community.centminmod.com/posts/20305/ but no idea of how to change or update the email address as yet :slight_smile:

Not only emails, but also other contact information that may be specified. https://acme-staging.api.letsencrypt.org/directory exposes only the new-reg endpoint and that endpoint doesn’t accept updates, because it has to respond with 409 Conflict for already existing keys.

We need to open an issue in the spec repository probably.

1 Like

See https://github.com/ietf-wg-acme/acme/issues/30.

1 Like

thanks @kelunik being able to update email addresses would be nice :slight_smile:

You can probably post an update to the registration object. At least it’s possible to update it with an agreement.

1 Like

That’s correct, it should be possible to update the registration object with a new email address, but I don’t think this is currently implemented in the official client. However, you should be able to do it by modifying the client or using a custom one.

2 Likes

Should be as simple as passing the contact along, as I’m requesting that resource anyway, because I don’t save registration objects offline currently.

1 Like

any plans for having email update in client by GA public release ?

I'm afraid not, sorry.

@jsha @schoen @kelunik @bmw that’s unfortunate as it should be a higher priority if security is a priority (up there with the rational for 90 day expiry policy). As what happens if you need to contact LE registered account users i.e. renewal notifications and their email addresses bounce, are invalid or mistyped ?

Maybe I’ll find some time to add that, should be relatively easy.

1 Like

@kelunik thanks… not if it’s easy to do, but maybe also come renewal time, you can do a recheck of registered email to ensure it’s valid ? i.e. MX records

not sure what you could do with such checks though, other than maybe also offer up an option for backup email address registration --email-backup flag just in case

We already have update_registration, I just need to find the right place to update the email, it’s probably just like the following then:

return self.update_registration(
            regr.update(body=regr.body.update(email=newmail)))
1 Like