[PR] feat(upstream): verify the upstream certificate against configurable CAs [apisix]

["nic-6443 (via GitHub)" <gi...@apache.org>]

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: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] feat(upstream): verify the upstream certificate against configurable CAs [apisix]

["nic-6443 (via GitHub)" <gi...@apache.org>]

nic-6443 merged PR #13863:
URL: https://github.com/apache/apisix/pull/13863


-- 
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: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org