ACME Providers Are Indistinguishable in Domain TLS Settings

Issue Description

When multiple ACME providers are configured using the same Let’s Encrypt directory URL, they cannot be distinguished in the Domain TLS settings.

For example, separate ACME providers may be configured for different tenants, but each provider is displayed only as:

https://acme-v02.api.letsencrypt.org/directory

Expected Behavior

Each ACME provider should have a configurable descriptive name. That name should be displayed in the TLS provider selection within the Domain TLS settings so administrators can identify and select the correct provider.

Actual Behavior

All ACME providers using the Let’s Encrypt production directory are displayed with the same directory URL. There is no descriptive name or other identifying information, making it impossible to determine which provider belongs to each tenant.

Reproduction Steps

  1. Create multiple ACME providers.
  2. Configure each provider to use the Let’s Encrypt production directory:
    https://acme-v02.api.letsencrypt.org/directory
  3. Configure the providers for different tenants or ACME accounts.
  4. Open the TLS settings for a domain.
  5. Open the ACME provider selection field.
  6. Observe that every provider is displayed using the same directory URL and cannot be distinguished.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

PostgreSQL

Blob Storage

S3-compatible

Search Engine

PostgreSQL

Directory Backend

Internal

Additional Context

This is being reported as a bug rather than a feature request because Stalwart already supports configuring multiple ACME providers and selecting a provider for a domain. However, when multiple providers use the same ACME directory URL, the interface provides no way to distinguish between them.

As a result, the existing multi-provider functionality cannot be used reliably because an administrator cannot determine which configured provider is being selected. Adding a descriptive name is one possible solution, but the underlying bug is that distinct provider configurations are displayed as identical options.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

This confirms the AcmeProvider object schema has no name/label field, just id, directory URL, contact, etc, so the WebUI has nothing but the id (an opaque string) or directory URL to display, confirming the reported behavior is expected given current data model.

Confirmed: the current AcmeProvider object has no descriptive name or label field, only directory, challengeType, contact, accountKey, accountUri, renewBefore, maxRetries, memberTenantId, preferredChain, and reuseKey (see the AcmeProvider reference). Since the object ID itself isn’t surfaced as a human-readable label in the picker either, two providers pointing at the same Let’s Encrypt directory really are indistinguishable in the Domain TLS settings UI today, there’s no config field (like the name field that other objects such as AiModel have) to use as a display label instead.

This is a legitimate gap rather than something addressed elsewhere in the docs, so your report is accurate as filed. A human maintainer will need to weigh in on adding a name/description field to the AcmeProvider schema and using it in the WebUI selector.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

Fixed in v0.16.17 (yet to be released).

The new label fields are also all identical and do not provide any means of distinguishing the entries.

Fixed. v0.16.18 will show the provider URL plus the unique accountUri instead of the email address. If that does not help, a new user defined description field has to be added to the schema as there are no other properties to uniquely identify a provider.

For anyone else following this thread, in v0.16.18 this is now the interface. You will still need to cross reference the URI back to the ACME Providers, but at least you can narrow it down.