pastilhasandClaude Opus 5
867226d897
the whole reason the credential store exists. a tailnet-only hostname cannot be reached on port 80, so HTTP-01 is impossible and a DNS record is the only proof Let's Encrypt accepts — which needs the provider's API key. POST /domains/certificate is the one route here that is deliberately not a pass-through, and it has to be: the request needs dns_provider_credentials, and officer never returns a stored key to any caller. so the platform resolves which provider owns the name from the Domains list, decrypts, builds the request and returns NPM's own answer unchanged. same arrangement as the NPM token one level up — the thing that wants the work done is not the thing holding the password. NOT under /_config. reading and writing a DNS key stays owner-only; USING it on the owner's behalf is the feature, and gating this to the owner would defeat it. a read-level account still cannot reach it, because it is a POST. three refusals, all before anything is placed at the registrar: a name whose apex is not in the domain list, a provider with no key stored, and a certificate spanning two providers — NPM takes one credential per certificate, and discovering that halfway through leaves a challenge record behind. tested, because each one otherwise fails deep inside certbot with an error about something else. ten minute timeout, 120s default propagation. both err long on purpose: NPM waits for the record to spread before asking Let's Encrypt to look, and abandoning the request does not stop it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
24 lines
1.0 KiB
TypeScript
24 lines
1.0 KiB
TypeScript
import { describe, expect, test } from 'bun:test';
|
|
import { issueWithDnsChallenge } from './domains';
|
|
|
|
/**
|
|
* The refusals, which are the part worth testing.
|
|
*
|
|
* The happy path writes to Postgres and talks to NPM, so a test of it would be a test of this machine.
|
|
* What can be silently WRONG is which requests get through: a certificate built for a domain Officer does
|
|
* not know, or one spanning two providers, fails deep inside NPM after a challenge record has already been
|
|
* placed — and the error that comes back is about certbot rather than about the mistake.
|
|
*/
|
|
|
|
describe('issueWithDnsChallenge refuses before it can leave a mess', () => {
|
|
test('no names at all', async () => {
|
|
await expect(issueWithDnsChallenge({ domainNames: [] })).rejects.toThrow(/at least one domain/i);
|
|
});
|
|
|
|
test('a name that belongs to no stored domain', async () => {
|
|
await expect(issueWithDnsChallenge({ domainNames: ['not-a-domain-officer-knows.example'] })).rejects.toThrow(
|
|
/add the domain first/i,
|
|
);
|
|
});
|
|
});
|