installSsl's current implementation POSTs to the v2 certificate-creation endpoint (/orgs/{org}/servers/{server}/sites/{site}/domains/{domain}/certificates) without a letsencrypt object in the request body. Forge's API now requires it and rejects every call with a 422:
The letsencrypt field is required. (and 2 more errors)
- letsencrypt.verification_method: The letsencrypt.verification method field is required.
- letsencrypt.key_type: The letsencrypt.key type field is required.
Because this fails at request-validation time, the ACME flow is never reached — no certificate request is sent to LetsEncrypt and no server-side state changes. Low risk to run, but installSsl is currently 100% non-functional: every call fails before doing anything.
The method's own arguments schema (server, domain, domains, dryRun) has no way to supply the missing fields, so there's no workaround via input — the request body needs to be built with a nested letsencrypt object.
Confirmed working values by reading an already-installed certificate on a neighboring site via the same v2 API (GET .../sites/{site}/domains/{domain}/certificates):
{"type":"letsencrypt","verification_method":"http-01","key_type":"ecdsa", ...}
Working POST body, verified against Forge's API directly (bypassing the model) and confirmed to install successfully:
{"type":"letsencrypt","letsencrypt":{"verification_method":"http-01","key_type":"ecdsa"}}
Suggested fix: update installSsl to send type: "letsencrypt" plus a nested letsencrypt: { verification_method: "http-01", key_type: "ecdsa" } (or expose these as method inputs with those as defaults, for sites that need dns-01 or rsa instead).
No secrets, key material, or vault names are relevant to this report — it's a pure API schema issue.
Upstream repository: https://github.com/nathanworking/swamp-forge-provision
Environment
- Extension:
@goodcraft/forge@2026.07.21.2
- swamp:
20260721.174127.0-sha.0e77b06b
- OS:
darwin (aarch64)
- Deno:
2.8.3
- Shell:
/bin/zsh
installSsl's current implementation POSTs to the v2 certificate-creation endpoint (/orgs/{org}/servers/{server}/sites/{site}/domains/{domain}/certificates) without aletsencryptobject in the request body. Forge's API now requires it and rejects every call with a 422:Because this fails at request-validation time, the ACME flow is never reached — no certificate request is sent to LetsEncrypt and no server-side state changes. Low risk to run, but
installSslis currently 100% non-functional: every call fails before doing anything.The method's own arguments schema (
server,domain,domains,dryRun) has no way to supply the missing fields, so there's no workaround via input — the request body needs to be built with a nestedletsencryptobject.Confirmed working values by reading an already-installed certificate on a neighboring site via the same v2 API (
GET .../sites/{site}/domains/{domain}/certificates):{"type":"letsencrypt","verification_method":"http-01","key_type":"ecdsa", ...}Working POST body, verified against Forge's API directly (bypassing the model) and confirmed to install successfully:
{"type":"letsencrypt","letsencrypt":{"verification_method":"http-01","key_type":"ecdsa"}}Suggested fix: update
installSslto sendtype: "letsencrypt"plus a nestedletsencrypt: { verification_method: "http-01", key_type: "ecdsa" }(or expose these as method inputs with those as defaults, for sites that needdns-01orrsainstead).No secrets, key material, or vault names are relevant to this report — it's a pure API schema issue.
Upstream repository: https://github.com/nathanworking/swamp-forge-provision
Environment
@goodcraft/forge@2026.07.21.220260721.174127.0-sha.0e77b06bdarwin(aarch64)2.8.3/bin/zsh