Skip to main content

A dedicated domain for object storage

By default, objects can be accessed via https://Bucketname.s3.internet1.de/<key>. This guide shows three ways to use your own domain, such as files.example.com, instead.

OptionEffortOwn TLS certificate for the domainAdditional server required
A: CNAMElowno¹no
B: NGINX reverse proxymoderateyes (e.g. Let's Encrypt)yes
C: s3-proxymoderateyesyes

¹ With a pure CNAME, the storage system presents the certificate for *.s3.internet1.de – using HTTPS under its own domain therefore results in certificate warnings. CNAME is therefore primarily suitable for HTTP redirects or in combination with a CDN that terminates TLS.

Option A: CNAME record​

Prerequisite: The bucket name must match the desired domain exactly (bucket files.example.com) for the virtual-hosted mapping to work.

  1. Create a bucket named files.example.com; make any objects that are to be publicly accessible publicly accessible.
  2. Set a CNAME with your DNS provider:
files.example.com.  300  IN  CNAME  files.example.com.s3.internet1.de.
  1. Test: http://files.example.com/pfad/objekt.jpg
Info

For secure HTTPS on your own domain, use option B or C – or use a CDN with its own certificate as an intermediary.

Option B: NGINX reverse proxy​

A dedicated server (e.g. centron Cloud Server) handles TLS and forwards requests to the bucket.

  1. DNS: Point the A/AAAA record from files.example.com to the proxy server.
  2. Obtain a certificate, e.g. certbot --nginx -d files.example.com.
  3. NGINX configuration /etc/nginx/sites-available/files.example.com:
server {
    listen 443 ssl http2;
    server_name files.example.com;

    ssl_certificate     /etc/letsencrypt/live/files.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/files.example.com/privkey.pem;

    # Optionaler Cache für ausgelieferte Objekte
    # proxy_cache_path /var/cache/nginx keys_zone=s3cache:10m max_size=10g; (im http-Block)

    location / {
        proxy_pass https://mein-bucket.s3.internet1.de/;
        proxy_set_header Host mein-bucket.s3.internet1.de;
        proxy_ssl_server_name on;

        # Interne S3-Header nicht an Clients durchreichen
        proxy_hide_header x-amz-request-id;
        proxy_hide_header x-amz-id-2;

        # Größere Uploads erlauben, falls PUT durchgereicht wird
        client_max_body_size 0;
    }
}

server {
    listen 80;
    server_name files.example.com;
    return 301 https://$host$request_uri;
}
  1. Activate and reload:
ln -s /etc/nginx/sites-available/files.example.com /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Note: In this basic configuration, only publicly accessible objects are served. If private objects are to be served, the proxy must sign requests – Option C is suitable for this.

Option C: s3-proxy​

s3-proxy is a lightweight proxy that self-signs requests, thereby making private buckets accessible under your own domain – including optional authentication, templates and directory listings.

Example using Docker Compose:

services:
  s3-proxy:
    image: oxynozeta/s3-proxy:latest
    ports:
      - "8080:8080"
    volumes:
      - ./config:/proxy/conf

./config/config.yaml:

targets:
  files:
    mount:
      path:
        - /
    bucket:
      name: mein-bucket
      region: 
      s3Endpoint: https://s3.internet1.de
      credentials:
        accessKey:
          env: S3_ACCESS_KEY
        secretKey:
          env: S3_SECRET_KEY

Pass the access credentials as environment variables and publish the service behind NGINX (Option B, proxy_pass http://127.0.0.1:8080;) using TLS.

Recommendation​

  • Public assets, minimal effort: Option A (+ CDN for HTTPS)
  • Full control over TLS, caching and headers: Option B
  • Private buckets under your own domain: Option C
Last updated on