Object Storage - Encrypt your server-side objects with SSE-C or SSE-OMK

Objective

OVHcloud S3¹-compatible Object Storage supports two server-side encryption (SSE) methods to protect your objects at rest:

• SSE-C (Server-Side Encryption with Customer Keys): you supply a 256-bit AES key with every request. You retain full control over keys, but you are responsible for storing and rotating them.
• SSE-OMK (Server-Side Encryption with OVHcloud-Managed Keys): OVHcloud automatically generates and manages a unique encryption key per object. No key management required.
• A third option, Client-Side Encryption (CSE), lets you encrypt data before sending it to Object Storage. This guide includes CSE in the comparison table below but does not cover its implementation in detail.

This guide explains how to encrypt your server-side objects with SSE-C or SSE-OMK.

Choosing a method

Use SSE-C when compliance or audit requirements mandate exclusive key ownership. Use SSE-OMK for transparent, zero-effort encryption.

Requirements

• An Object Storage bucket
• A user with the required access rights on the bucket
• AWS CLI installed and configured

See our Getting started with Object Storage guide.

OVHcloud Control Panel Access

• Direct link: Public Cloud Projects
• Navigation path: Public Cloud > Select your project

Instructions

SSE-C — Server-Side Encryption with Customer Keys

When you upload an object with SSE-C, Object Storage applies AES-256 encryption using the key you provide. To retrieve the object later, you must supply the same key — Object Storage verifies it before decrypting.

Each request requires three headers:

Generating an encryption key

secret=$(openssl rand 32)
encKey=$(echo -n "$secret" | base64)
md5Key=$(echo -n "$secret" | openssl dgst -md5 -binary | base64)

Uploading an object

aws s3api put-object \
  --body <file_path> \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key"

Downloading an object

aws s3api get-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key" \
  <destination_file_path>

Omitting the encryption headers returns a 400 Bad Request error.

Retrieving object metadata

aws s3api head-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "$encKey" \
  --sse-customer-key-md5 "$md5Key"

Example output:

{
    "LastModified": "Tue, 19 Apr 2022 09:38:47 GMT",
    "ContentLength": 111,
    "ETag": "\"272913026300e7ae9b5e2d51f138e674\"",
    "VersionId": "1650376416551536",
    "ContentType": "binary/octet-stream",
    "Metadata": {},
    "StorageClass": "STANDARD"
}

Without encryption headers, you will get a 400 Bad Request error.

Deleting an encrypted object

Deletion does not require encryption headers:

aws s3 rm s3://<bucket_name>/<object_key>

Presigned URLs

Presigned URLs support SSE-C with the following requirements:

• When generating the URL, include x-amz-server-side-encryption-customer-algorithm in the signature calculation.
• When using the URL, the client must supply all three SSE-C headers.

SSE-OMK — Server-Side Encryption with OVHcloud-Managed Keys

SSE-OMK encrypts objects automatically at rest. OVHcloud derives a unique key per object (combining a per-bucket master key with a random salt), so each object is protected individually with no management overhead on your part. Downloads are fully transparent — no encryption headers needed.

Advantages

• Simplified key management: OVHcloud handles key generation, storage, and rotation. No administrative overhead or key rotation schedules for your team.
• Per-object isolation: each object is encrypted with its own derived key, so a potential key compromise affects only that object, not your entire bucket.
• Transparent access: encrypted objects behave exactly like unencrypted ones — no changes to your application or workflows.

Uploading an object

aws s3api put-object \
  --bucket <bucket_name> \
  --key <object_key> \
  --body <file_path> \
  --server-side-encryption AES256 \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Downloading an object

No encryption headers are needed — decryption is handled automatically server-side:

aws s3api get-object \
  --bucket <bucket_name> \
  --key <object_key> \
  <destination_file_path> \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Enabling SSE-OMK on a bucket

Once enabled, all subsequent uploads are encrypted automatically. Existing objects are unaffected — re-upload them to encrypt retroactively.

AWS CLI

OVHcloud Control Panel

aws s3api put-bucket-encryption \
  --bucket <bucket_name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}' \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

In the left-hand menu, click Object Storage under Storage & backup. Select your bucket, then click Enable encryption in the information panel.

Click Enable to confirm.

Verifying bucket encryption

AWS CLI

OVHcloud Control Panel

aws s3api get-bucket-encryption \
  --bucket <bucket_name> \
  --endpoint-url https://s3.<region>.io.cloud.ovh.net

Open the bucket information panel and check the Security and permissions section. The Encryption Default field shows whether SSE-OMK is enabled.

Deleting an encrypted object

Deletion works exactly the same as for unencrypted objects:

aws s3 rm s3://<bucket_name>/<object_key>

Considerations

• Encryption overhead: SSE-OMK adds a negligible latency overhead for most workloads. To minimize it, use a bucket region geographically close to your application.
• Key visibility: you cannot inspect, rotate, or audit the encryption keys directly. If your compliance framework requires key ownership or audit trails, use SSE-C instead.
• Defence in depth: SSE-OMK protects data at rest, but does not replace access control. Pair it with strict IAM policies and access logging to monitor and restrict who can read your objects.

Recommended use cases

CSE (Client-Side Encryption)

• Ideal for organizations with very high security requirements, requiring encryption keys to remain under exclusive control.
• Suited to highly regulated industries such as finance and healthcare.

SSE-C (Server-Side Encryption with Customer Keys)

• Suited to organizations that need to audit or rotate their own keys but want to delegate the encryption workload to the server.
• Use when compliance mandates key ownership without the full complexity of client-side encryption.

SSE-OMK (Server-Side Encryption with OVHcloud-Managed Keys)

• Best for teams that want robust encryption without the operational burden of key management.
• Ideal when simplicity and speed of deployment are priorities and there are no key-ownership compliance requirements.

Troubleshooting

Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analyzed by our experts.

Join our community of users.

¹: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.