shreemaan-abhishek commented on PR #2826:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2826#issuecomment-5421085710
Added in `70bc09e3` — `test/e2e/crds/v1alpha1/gatewayproxy_tls.go`, labelled
`apisix.apache.org, v1alpha1, gatewayproxy` so it runs in the existing matrix.
The admin API only listens on plain HTTP, so the spec puts an openresty in
front of it to stand in for a control plane published over TLS. Its certificate
is signed by a CA generated per test, which is exactly the case `caBundle`
exists for: nothing in the system trust store can verify it. That image is
already pulled and loaded by `make kind-load-images`, so no new dependency.
Three specs:
| spec | asserts |
| --- | --- |
| `syncs to a private-CA control plane when caBundle is trusted` | route is
programmed and serves 200 — the sync got through TLS verification |
| `fails to sync when caBundle is missing` | controller logs `unable to
verify the first certificate`, and the route is never programmed |
| `rejects a caBundle that is not a certificate` | the API server rejects it
via the CEL rule |
Run locally against kind, both provider modes:
```
PROVIDER_TYPE=apisix-standalone make e2e-test TEST_FOCUS='control plane TLS'
Ran 3 of 237 Specs in 97.522 seconds -- SUCCESS! 3 Passed | 0 Failed
PROVIDER_TYPE=apisix make e2e-test TEST_FOCUS='control plane TLS'
Ran 3 of 236 Specs in 115.785 seconds -- SUCCESS! 3 Passed | 0 Failed
```
Writing it turned up something worth flagging separately: the spec generates
its certificates locally instead of using `scaffold.GenerateMACert`, because
that helper gives the CA and the leaf **the same subject** (`O=Acme Co`, no CN)
— `ssl.go:150` and `ssl.go:180`. OpenSSL reads such a leaf as self-issued and
fails with `DEPTH_ZERO_SELF_SIGNED_CERT` without ever chaining to the CA. My
first run failed on exactly that, with the controller sending everything
correctly:
```
"config": {...,"tlsVerify":true,"hasCaBundle":true}
"error": ... HTTP 500: {"message":"Error: self-signed certificate; ..."}
```
It goes unnoticed today because the current callers verify with Go's x509
(webhook `caBundle`) or use the CA only as a client-auth trust anchor, neither
of which trips that OpenSSL check. Happy to fix the helper in a follow-up if
you'd like — I kept it out of this PR to avoid touching the certificates other
specs depend on.
--
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]
