Staging certificate messages?

[rg305]

@JamesLE

Yes, unsubscribing will affect all messages from any environment.

@JamesLE, Just to cover all bases, can you re-register using an email address that has previously requested to be unsubscribed?
If not, is there a specific wait time involved - or any other relevant details?
[subscribe - unsubscribe - (re)subscribe]

[JamesLE]

@rg305

can you re-register using an email address that has previously requested to be unsubscribed?

No, unfortunately, we don't currently have the integration plumbed through to our ESP that this would need. Unsubscriptions currently last for one year.

[bnicer]

@griffin

As an ACME client author myself (CertSage), I can absolutely assure you that you don't need to register an email address when creating an ACME account. Whether the particular ACME client you are using allows such operation is up to the author of that client.

I think the simplest way is to just try it.

I ran a "staged" renewal without the --emailaddress parameter. As I did not get a notification afterwards, it probably disabled email notifications on the account. On the downside, the "staging" certificate has a new expiry date = 10.12.2021. (90 days)

In September I will know for a fact whether the Expiry Bot still sends "staging" messages before the certificate is about to expire.

What other way is there to check if the email message feature is still active?

EDIT: Correction. I was just notified of the renewal to my email address. So leaving out the email in the command was a nonstarter, apparently, at least for the domain and the existing account.

[griffin]

Keep in mind that if you've already registered an ACME staging account due to a previous run, not specifying the email parameter will simply keep using the email address already registered for your account. You would need to create a new account (with a new private key) in order to really test this.

[bnicer]

With a new private key, I'm prompted for an email address.

Enter email(s) for notifications about problems and abuse (comma-separated):

Ignoring the input and proceeding, and importantly removing sender and receiver addresses in the JSON file works.

As for the old key and "staging" account, I guess I'll wait for the expiry. Revoking the certificate is too much trouble right now.

[griffin]

@bnicer

removing sender and receiver addresses in the JSON file

Why would there be addresses in a clean account file? The address on the Let's Encrypt server (or lack of an address) is what matters.

[rmbolger]

@griffin

You would need to create a new account (with a new private key) in order to really test this.

…only if one’s client doesn’t support modifying the contact field on an existing account which I would hope is not terribly common. The protocol allows for updates to the contact field most commonly so you can change the associated email. But it can also be changed to an empty list effectively unregistering the existing email address(es) from notifications for orders associated with that account.

[griffin]

Thanks for answering several questions that have been floating around in my head, @rmbolger.

I think that updating the email address(es) on file is within the purview of many ACME clients, but erasing the address(es) is likely not within their designed functionality.

[rmbolger]

@griffin

I think that updating the email address(es) on file is within the purview of many ACME clients, but erasing the address(es) is likely not within their designed functionality.

You’re probably right. I recall making sure my client could do it pretty late in the dev cycle on the initial version.

[griffin]

For a command-line parameter it would basically require an empty set of quotes to be passed with the parameter (or a special "clear" parameter to be available). If the standard calling protocol doesn't support such, I don't think there's much hope.

Since CertSage uses an HTML form for input and the email field is not specified as required, the PHP backend always receives something for it. If the user leaves the email field empty, this signifies that CertSage shouldn't attempt to update the email address. It's certainly a case where two different paths of logic could be considered. A command-line parameter can handle both cases via submission of an empty input or omission of the parameter entirely.

[rmbolger]

The way Posh-ACME works is that the Contact parameter in the account modification function will either accept an empty array @() or a literal null value $null like this:

Set-PAAccount -Contact @()
# or
Set-PAAccount -Contact $null

Not specifying the Contact parameter at all indicates you don't want to change it.

[griffin]

So which does what?

Do both existent ways submit an empty change?

[rg305]

I read that as: In Posh-ACME they both do the same thing.

[griffin]

Two roads, one outcome. Hope this is documented.

[rmbolger]

The @() method is the "most correct" because an empty JSON list ("contact": []) is ultimately what is getting sent in the request. But idiomatic PowerShell can allow for $null values in parameters like this, so the function will recognize and translate $null into the empty list as a convenience feature rather than throwing an error.

@griffin

Hope this is documented.

The Contact parameter is documented, but it doesn't look like I have any notes about how to wipe the list. So thanks for the reminder!

[griffin]

@rmbolger

it doesn't look like I have any notes about how to wipe the list.

Shame, shame, shame, shame, shame!

It happens to the best of us. Unfortunately, our users are typically not code whisperers.

[griffin]

@rmbolger

But idiomatic PowerShell can allow for $null values in parameters like this, so the function will recognize and translate $null into the empty list as a convenience feature rather than throwing an error.

I feel you on the idiomatic behavior. PHP went so far as to add a "null coalescing operator" (??) as "syntactic sugar".

Instead of the usual, monotonous check and set:

$username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

we can now use a shorthand:

$username = $_GET['user'] ?? 'nobody';

---

I still find one of the fundamental ironies in PHP to be this:

A variable is considered to be null if:

it has been assigned the constant null.

it has not been set to any value yet.

it has been unset().

yet this function returns an error if passed a variable that has not been set (and is thus considered to be null):

is_null(mixed $value): bool

while having this return definition:

Returns true if value is null, false otherwise.

while this function does not return an error if passed a variable that has not been set (and is thus considered to be null):

isset(mixed $var, mixed ...$vars): bool

while having this return definition:

Returns true if var exists and has any value other than null. false otherwise.

So... setting a variable to null means that it does exist, but is not set.

Yeah. It's that goofy.