Context
Engine PR achird-labs/rift#980 (issue achird-labs/rift#977) implements mutual TLS on HTTPS imposters. mutualAuth had been documented in docs/features/tls.md while ImposterConfig silently dropped it — a user following the docs to require client certificates got a listener that accepted everyone.
Three imposter-config keys now exist and are honoured:
| Key |
Type |
Meaning |
mutualAuth |
bool |
Request and require a client certificate. https only. |
rejectUnauthorized |
bool |
Validate the client certificate against ca. Requires ca. |
ca |
string or array of strings |
PEM trust anchor(s) client certificates must chain to. |
Two separate asks
1. Compatibility — please check, this one can break a working config
The engine now refuses at creation (HTTP 400) every combination that cannot take effect, where before the keys were dropped on parse and the imposter was created:
rejectUnauthorized or ca without mutualAuthca without rejectUnauthorizedrejectUnauthorized without ca (including ca: [])- a
ca containing no certificate
mutualAuth: true on protocol: "http" (false stays valid)
rejectUnauthorized without mutualAuth is valid Mountebank, so any fixture, sample, or test config in this SDK that carries it — and that previously created an imposter fine — will now get a 400 against a current engine. Please grep your fixtures and example configs for rejectUnauthorized, mutualAuth and ca.
If nothing carries them, this half is a no-op; say so on the issue and close it out.
2. Adoption — optional
If the SDK exposes a typed imposter builder, surface the three keys so users can express mTLS without hand-writing JSON. Note that none of the SDKs currently model imposter cert/key either, so this may be part of a larger "HTTPS imposters in the DSL" piece rather than three fields on their own.
Version gating
These are imposter-config keys, not serve options, so serveOptions presence-detection does not cover them. An engine older than this release ignores all three silently (that is the bug being fixed). If the SDK needs to behave differently against an older engine, gate on the engine version rather than on a probe.
Not doing
The sdk-conformance corpus is deliberately not gaining an HTTPS/mTLS fixture for this. It has no HTTPS fixture at all today, and adding one would force a schemaVersion bump across all four SDK repos for a feature none of their typed DSLs can express yet. If HTTPS imposters land in the DSLs, the corpus is the right follow-up then.
Refs: achird-labs/rift#977 (engine issue), achird-labs/rift#980 (engine PR).
Context
Engine PR achird-labs/rift#980 (issue achird-labs/rift#977) implements mutual TLS on HTTPS imposters.
mutualAuthhad been documented indocs/features/tls.mdwhileImposterConfigsilently dropped it — a user following the docs to require client certificates got a listener that accepted everyone.Three imposter-config keys now exist and are honoured:
mutualAuthhttpsonly.rejectUnauthorizedca. Requiresca.caTwo separate asks
1. Compatibility — please check, this one can break a working config
The engine now refuses at creation (HTTP 400) every combination that cannot take effect, where before the keys were dropped on parse and the imposter was created:
rejectUnauthorizedorcawithoutmutualAuthcawithoutrejectUnauthorizedrejectUnauthorizedwithoutca(includingca: [])cacontaining no certificatemutualAuth: trueonprotocol: "http"(falsestays valid)rejectUnauthorizedwithoutmutualAuthis valid Mountebank, so any fixture, sample, or test config in this SDK that carries it — and that previously created an imposter fine — will now get a 400 against a current engine. Please grep your fixtures and example configs forrejectUnauthorized,mutualAuthandca.If nothing carries them, this half is a no-op; say so on the issue and close it out.
2. Adoption — optional
If the SDK exposes a typed imposter builder, surface the three keys so users can express mTLS without hand-writing JSON. Note that none of the SDKs currently model imposter
cert/keyeither, so this may be part of a larger "HTTPS imposters in the DSL" piece rather than three fields on their own.Version gating
These are imposter-config keys, not serve options, so
serveOptionspresence-detection does not cover them. An engine older than this release ignores all three silently (that is the bug being fixed). If the SDK needs to behave differently against an older engine, gate on the engine version rather than on a probe.Not doing
The
sdk-conformancecorpus is deliberately not gaining an HTTPS/mTLS fixture for this. It has no HTTPS fixture at all today, and adding one would force aschemaVersionbump across all four SDK repos for a feature none of their typed DSLs can express yet. If HTTPS imposters land in the DSLs, the corpus is the right follow-up then.Refs: achird-labs/rift#977 (engine issue), achird-labs/rift#980 (engine PR).