stalwart: record that the public-side ACME path is not fully verified

The private direction of the mode switch is exercised end to end. The
public one has only ever run against a throwaway .test domain, where Let's
Encrypt rejects the contact address before the provider is created — so
everything past that call is reasoned rather than observed.

The plan shape IS confirmed up to that point: contact is a set, matchOn is
the directory URL, and a domain cannot reference automatic certificate
management without an acmeProviderId. What is unproven is the link holding
once the provider actually exists.

Saying so in the file beats leaving it in a chat log nobody reads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
librelad 2026-08-19 00:23:45 +01:00
parent 81c672c474
commit e14e295f3f

View File

@ -70,6 +70,14 @@ appStalwartSetMode() {
# server that was private has never had one — so create it here # server that was private has never had one — so create it here
# rather than failing with "ACME provider not found". # rather than failing with "ACME provider not found".
# #
# NOT FULLY VERIFIED. The private direction below is exercised end to
# end, but this one has only ever been run against a throwaway .test
# domain, where Let's Encrypt refuses the contact address before the
# provider is created — so the AcmeProvider -> Domain link past that
# point is reasoned, not observed. The plan shape is confirmed up to
# the LE call (contact is a set, matchOn is the directory URL, an
# acmeProviderId is required). Worth one run on a real domain.
#
# Two things about this are worth knowing. Creating the provider # Two things about this are worth knowing. Creating the provider
# REGISTERS AN ACCOUNT with Let's Encrypt there and then, so it is a # REGISTERS AN ACCOUNT with Let's Encrypt there and then, so it is a
# real outbound action, not a local setting. And the challenge type # real outbound action, not a local setting. And the challenge type