Restore fails with x509: certificate signed by unknown authority when using custom CA bundle with MinIO storage (PSMDB Operator 1.22.0)

[amerello]

Report

Summary

Backups complete successfully using a MinIO-compatible storage with a custom CA bundle (self-signed / internal CA), but restore operations fail during the backup validation phase with a classic TLS certificate verification error:

tls: failed to verify certificate: x509: certificate signed by unknown authority

The error occurs when PBM tries to perform a HEAD request on the .pbm.json metadata file in storage.

This strongly suggests that the caBundle setting defined in the PerconaServerMongoDB.spec.backup.storages section is not being propagated / used by the restore process (or by the PBM agent during the pre-restore validation step).

Affected version

• Percona Server for MongoDB Operator: 1.22.0

Current configuration (relevant excerpt)

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDB
spec:
  backup:
    enabled: true
    storages:
      main:
        type: minio
        minio:
          bucket: backup-bucket
          credentialsSecret: my-cluster-name-backup-minio
          endpointUrl: my-s3-compatible-storage.example.com   # HTTPS endpoint
          prefix: backup
          region: us-east-1
          secure: true
          caBundle:
            name: single-root-ca-certificate
            key: single-root-ca-certificate.crt
        main: true
    tasks:
    - name: daily
      enabled: true
      schedule: "25 * * * *"
      storageName: main
      compressionType: gzip
      retention:
        type: count
        count: 7
        deleteFromStorage: true

The corresponding PerconaServerMongoDBBackup CR status shows the backup completed successfully and also contains the same caBundle configuration:

status:
  minio:
    bucket: backup-bucket
    caBundle:
      key: single-root-ca-certificate.crt
      name: single-root-ca-certificate
    endpointUrl: my-s3-compatible-storage.example.com
    prefix: backup
    region: us-east-1
    secure: true
  state: ready

Observed behavior during restore

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDBRestore
metadata:
  name: my-cluster-restore
spec:
  clusterName: my-cluster-psmdb
  backupName: cron-my-cluster--20260226094000-dz85m

status:
  state: error
  error: >-
    failed to validate backup: validate backup in storage: get backup metadata
    from storage: get from store: list with parts for mw source reader: fetching pbm
    file parts base for 2026-02-26T09:40:00Z.pbm.json: get using minio: Head
    "https://my-s3-compatible-storage.example.com/backup-bucket/backup/2026-02-26T09%3A40%3A00Z.pbm.json":
    tls: failed to verify certificate: x509: certificate signed by unknown authority

Expected behavior

The restore process should respect the same caBundle configuration that was successfully used during backup → it should trust the custom CA and be able to read the metadata file.

Suspected root cause

The caBundle is correctly applied during backup operations (PBM agent writes to storage successfully), but not applied (or not mounted/used) during restore validation or when the operator/PBM agent reads back the backup metadata.

Thanks for looking into this!

More about the problem

Backups complete successfully using a MinIO-compatible storage with a custom CA bundle (self-signed / internal CA), but restore operations fail during the backup validation phase with a classic TLS certificate verification error.

Steps to reproduce

1. Deploy a PSMDB cluster (sharded or replica set) using Operator ≥ 1.22.0
2. Configure a MinIO-compatible S3 storage with HTTPS + custom/internal CA
3. Add caBundle secret reference in the storage configuration
4. Create & complete a logical backup (succeeds)
5. Create a PerconaServerMongoDBRestore CR pointing to that backup (fails)

Versions

1. Kubernetes v1.33.1
2. Operator percona/percona-server-mongodb-operator:1.22.0
3. Database: percona/percona-server-mongodb:8.0.19-7
4. Backup Agent: percona/percona-backup-mongodb:2.12.0

Anything else?

No response

[amerello]

The situation also seems to affect the deletion of backups, since this runs on the operator and the operator doesn't consider the custom caBundle, the deletion of backups fails.

[egegunes]

@nmarukovich could you please try to reproduce this?

[nmarukovich]

Thank for your report! We preparing the fix. It will be available in the next release (1.23)

[amerello]

Hi @nmarukovich, this is great news. Many thanks!