nic-6443 opened a new pull request, #13863:
URL: https://github.com/apache/apisix/pull/13863
### Description
`upstream.tls.verify` has been in the schema for a while, but only the
`kafka` scheme ever read it — for an `https`/`grpcs` upstream APISIX connected
without ever checking the certificate it was handed. This makes the field mean
what it says for those schemes, and adds `upstream.tls.ca_certs` so the trust
anchors can be picked per upstream instead of only globally through
`ssl_trusted_certificate`.
```json
{
"scheme": "https",
"type": "roundrobin",
"nodes": { "127.0.0.1:8443": 1 },
"tls": {
"verify": true,
"ca_certs": ["<content of ca.crt>"]
}
}
```
Both settings are applied with the apisix-nginx-module upstream API
(`set_ssl_verify` / `set_ssl_trusted_store`), so this needs APISIX-Runtime — on
a plain OpenResty build a route carrying either field gets the usual "need to
build APISIX-Runtime" error instead of a nil call.
A few details worth calling out:
* `verify` loses its `false` default. Unset now means "fall back to the
nginx configuration", which is what happens today; the `kafka` scheme reads a
nil exactly the way it read a `false`, so nothing changes there.
* `grpcs` cannot apply these in `set_by_route`. Both settings live in the
apisix-nginx-module request context, and `ngx.exec("@grpc_pass")` goes through
`ngx_http_named_location()`, which zeroes `r->ctx` — the same reason the client
certificate is already re-applied from `grpc_access_phase`. So `grpcs` applies
them there.
* The parsed `X509_STORE` is cached under the `ca_certs` array itself rather
than under the config version. In standalone mode every resource loaded in one
reload shares a `modifiedIndex`, so a version-keyed entry would hand one
upstream's CA certificates to another.
* `ca_certs` set without a client certificate needs
api7/apisix-nginx-module#126, which moves `SSL_set1_verify_cert_store()` out of
the client-certificate branch. Until that lands in a runtime release,
`ca_certs` takes effect alongside `tls.client_cert`/`tls.client_cert_id`;
`tls.verify` itself is unaffected.
#### Which issue(s) this PR fixes:
N/A
### Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [x] I have updated the documentation to reflect this change
- [x] I have verified that this change is backward compatible (If not,
please discuss on the [APISIX mailing
list](https://github.com/apache/apisix/tree/master#community) first)
### Tests
`t/node/upstream-tls2.t` covers `verify` on its own, over both `https` and
`grpcs`; the `grpcs` block fails without the `grpc_access_phase` half of the
change. `t/node/upstream-mtls2.t` covers `ca_certs`: a non-certificate entry
rejected by the Admin API, a CA that does not match, one that does, and several
CAs where only the last one anchors the chain.
`t/node/upstream-mtls.t` TEST 21 and TEST 23 set `tls.verify` on an https
upstream to check that it does not disturb the client certificate path. That
field is no longer inert there, and the test upstream serves a self-signed
certificate issued for another name, so they now ask for `false` — what they
were written to assert is unchanged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
