Does not work with http endpoint even with insecureTLSSkipVerify as true

[metalshanked]

Rancher Server Setup

• Rancher version: 2.10.2
• Installation option (Docker install/Helm Chart): Helm
• Kubernetes Version and Engine: 1.31.4

Describe the bug

The S3 compatible object store like minio does not work with http

failed to check if s3 bucket [rancher-backup] exists, error: Head
        "https://minio.k8:9000/rancher-backup/": http: server gave HTTP
        response to HTTPS client

apiVersion: resources.cattle.io/v1
kind: Backup
metadata:
  creationTimestamp: '2025-02-05T14:24:50Z'
  generation: 9
  managedFields:
    - apiVersion: resources.cattle.io/v1
      fieldsType: FieldsV1
  
      manager: backup-restore-operator
      operation: Update
      subresource: status
      time: '2025-02-05T14:59:17Z'
  name: s3-onetime-backup
  resourceVersion: '5314865'
  uid: f514eeb0-bc31-47c6-bc1b-54c4aefcc249
spec:
  encryptionConfigSecretName: ''
  resourceSetName: rancher-resource-set
  retentionCount: 10
  storageLocation:
    s3:
      bucketName: rancher-backup
      credentialSecretName: minio-creds
      credentialSecretNamespace: default
      endpoint: minio.k8:9000
      endpointCA: ''
      folder: rancherbackup
      insecureTLSSkipVerify: true
      region: us-east-1
status:
  backupType: ''
  conditions:
    - lastUpdateTime: '2025-02-05T14:59:17Z'
      message: >-
        failed to check if s3 bucket [rancher-backup] exists, error: Head
        "https://minio.k8:9000/rancher-backup/": http: server gave HTTP
        response to HTTPS client
      reason: Error
      status: 'False'
      type: Reconciling
    - lastUpdateTime: '2025-02-05T14:24:53Z'
      message: Retrying
      status: Unknown
      type: Ready
  filename: ''
  lastSnapshotTs: ''
  nextSnapshotAt: ''
  observedGeneration: 0
  storageLocation: ''
  summary: ''

[mallardduck]

Hey @metalshanked - Thanks for this report, however we're going to close this as wontfix. This behaviour is intended for a few reasons; some around our policy for HTTPs and some around the function of the insecureTLSSkipVerify setting.

The lack of HTTP-only S3 support is intended by design. We've chosen this for a number of reasons that revolve around protecting backup data. Because the backup tool may (or may not) contain sensitive data, and users may (or may not) be using resource encryption features - we require HTTPS to protect that data in transit.

The second concern is the intention and use of the insecureTLSSkipVerify setting. This setting is meant to communicate that it is an "insecure" option which configures "TLS to skip certification verification". It would not allow an HTTPS configured client to communicate with HTTP only server.

Because self-sign SSL/TLS certificates are free the expectation is that even users hosting S3 services internally can use self-signed HTTPS. And in that use-case is where the insecureTLSSkipVerify setting would be helpful.