Skip to content

SmooaiNextEdge: auto-validate us-east-1 viewer cert via DNS adapter (0.1.4)#3

Merged
brentrager merged 1 commit into
mainfrom
stage-c-cert-validation
Jun 11, 2026
Merged

SmooaiNextEdge: auto-validate us-east-1 viewer cert via DNS adapter (0.1.4)#3
brentrager merged 1 commit into
mainfrom
stage-c-cert-validation

Conversation

@brentrager

Copy link
Copy Markdown
Contributor

Problem

Dogfooding Stage C (SMOODEV-1791) on smooai's apps/web surfaced a real gap in SmooaiNextEdge: it creates the ACM viewer cert with validationMethod: 'DNS' but never publishes the validation records and never gates on aws.acm.CertificateValidation. On a Cloudflare-DNS app the cert sits in PENDING_VALIDATION, so when the CloudFront Distribution tries to attach it the deploy fails ("certificate doesn't exist, isn't valid…").

Fix

Mirror SST's own DnsValidatedCertificate:

  • Extend DnsAdapter with optional provider / createRecord / createCaa (the surface sst.cloudflare.dns() / sst.aws.dns() already expose).
  • When the adapter has createRecord: publish the ACM DNS-validation CNAMEs (de-duped across domain + SANs), add a CAA 0 issue "amazonaws.com" for non-Route53 zones, and gate viewerCertificate on a CertificateValidation (us-east-1 provider, dependsOn the records).
  • Validation CNAMEs stay grey-cloud — SST's cloudflare adapter only proxies alias records, exactly what ACM needs.
  • No createRecord (or no dns) → unchanged behavior: raw (PENDING) arn, manual/out-of-band validation.

Bumps @smooai/deploy0.1.4.

Test

pnpm sst install && pnpm typecheck green against the SST platform ambient types (the PR-checks constructs gate). Behavior validated end-to-end by Stage C Phase 1 (smooai web-next.smoo.ai).

🤖 Generated with Claude Code

… via the DNS adapter (0.1.4)

Dogfooding Stage C surfaced a gap: the construct created the ACM viewer cert
(validationMethod: DNS) but never published the validation records or gated on
an aws.acm.CertificateValidation. On a Cloudflare-DNS app the cert stays
PENDING_VALIDATION and CloudFront refuses to attach it — the deploy fails.

Mirror SST's DnsValidatedCertificate: when the DNS adapter exposes createRecord,
publish the ACM DNS-validation CNAMEs (de-duped) + a CAA(amazonaws.com) for
non-Route53 zones, then gate the distribution's viewerCertificate on a
CertificateValidation (us-east-1 provider). Validation CNAMEs are never proxied
(SST's cloudflare adapter only proxies alias records), as ACM requires. No
createRecord on the adapter → unchanged behavior (raw PENDING arn, manual
validation). Extend DnsAdapter with optional provider/createRecord/createCaa.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Jun 11, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: b7ba2da

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@brentrager brentrager merged commit 49d1fca into main Jun 11, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant