Description:
In the Oracle MySQL Operator backup pod, mysqlsh util.dumpInstance fails when writing to an S3-compatible HTTPS endpoint with a custom CA. The S3 Secret includes ca.crt and is mounted to /mysqlsh/.aws; even
with AWS_CA_BUNDLE=/mysqlsh/.aws/ca.crt, mysqlsh exits with SSL certificate problem: unable to get local issuer certificate (CURLcode = 60).
In the same container, curl https://<endpoint> works using the same CA from the Secret.
Operator code path: mysqloperator/controller/backup_main.py calls shell.connect(backup_source) without ssl-ca/ssl-mode; storage_api.py only mounts the S3 Secret to /mysqlsh/.aws (no system trust path). MySQL Shell seems to ignore the provided CA for S3 HTTPS.
How to repeat:
1. Run the MySQL Operator backup container (as in upstream operator commit 3b14f90).
2. Provide an S3 Secret with accessKey, secretKey, config, and ca.crt; mount to /mysqlsh/.aws/. Optionally set AWS_CA_BUNDLE=/mysqlsh/.aws/ca.crt.
3. Trigger a backup via operator flow (or manually): mysqlsh connects to cluster and runs util.dumpInstance with S3 options (endpoint uses the custom CA).
4. Observe failure: RuntimeError: SSL certificate problem: unable to get local issuer certificate (CURLcode = 60).
5. In the same container, curl https://<endpoint> succeeds using /mysqlsh/.aws/ca.crt.
6. If you additionally mount ca.crt onto /etc/ssl/certs/ca-certificates.crt (or /etc/pki/tls/certs/ca-bundle.crt), the backup succeeds—showing mysqlsh/libcurl is not picking up the CA from AWS_CA_BUNDLE/~/.aws/ca.crt.
Suggested fix:
- Ensure mysqlsh respects AWS_CA_BUNDLE and/or ~/.aws/ca.crt for S3 HTTPS in util.dumpInstance (libcurl CA handling).
- Alternatively, extend the operator to pass sslCa/sslMode to shell.connect or to the S3 client used by util.dumpInstance.
- Current workaround: mount ca.crt from the S3 Secret to system trust paths so libcurl finds it.
