Google Cloud Storage

Overview

AutoSSL can automatically upload SSL certificate files to a Google Cloud Storage bucket. Each certificate is archived under a versioned archive path and also updated under a latest/ path for easy discovery by downstream consumers (e.g., Nginx, Caddy, or custom scripts that pull certificates from Cloud Storage).

For instructions on how to manage and run this deployment, please refer to the Deployment Management section.

Configuration Parameters

When you add or edit this deployment target in the AutoSSL console, you will need to configure the following parameters:

Parameter	Description	Example
Bucket Name	The name of the Cloud Storage bucket to upload certificate files to.	`my-ssl-certs`
Object Key Prefix	(Optional) A prefix for organizing certificate files in the bucket. If set, files will be uploaded under this prefix. Trailing slash is optional.	`certs/example.com/`

How it Works

When AutoSSL deploys a certificate to a Cloud Storage bucket (e.g., my-ssl-certs with prefix certs/example.com/), it performs the following steps:

Certificate Preparation:
- Splits the full certificate chain into individual PEM files: cert.pem (leaf certificate), privkey.pem (private key, PKCS#8 encoded), chain.pem (intermediate chain), and fullchain.pem (full chain).
- Generates a README.md file with certificate metadata and a link to https://autossl.dev for traceability.
- Parses the certificate notBefore date and SHA1 fingerprint to generate an archive directory name (format: YYYY-MM-DD_<first 8 chars of SHA1>).
File Upload:
- Uploads certificate files (four PEM files and README.md) to two paths in the bucket:
  - Archive path — certs/example.com/2026-05-30_e5f6a7b8/cert.pem (and privkey.pem, chain.pem, fullchain.pem, README.md). This path is unique per certificate issuance and is never overwritten.
  - Latest path — certs/example.com/latest/cert.pem (and privkey.pem, chain.pem, fullchain.pem, README.md). This path always reflects the most recently uploaded certificate.

The latest/ path allows downstream services to always fetch the current certificate from a fixed Cloud Storage key. Historical certificates remain accessible under their versioned archive directories.

Example Bucket Structure

After multiple certificate renewals, your bucket structure will look like this:

certs/example.com/
├── 2026-03-01_a1b2c3d4/
│   ├── cert.pem
│   ├── privkey.pem
│   ├── chain.pem
│   ├── fullchain.pem
│   └── README.md
├── 2026-05-30_e5f6a7b8/
│   ├── cert.pem
│   ├── privkey.pem
│   ├── chain.pem
│   ├── fullchain.pem
│   └── README.md
└── latest/
    ├── cert.pem
    ├── privkey.pem
    ├── chain.pem
    ├── fullchain.pem
    └── README.md

Private Key Format

privkey.pem is encoded in PKCS#8 format (-----BEGIN PRIVATE KEY-----). This format is widely supported by modern web servers and tools (Nginx, Caddy, Traefik, OpenSSL 1.1+, etc.).

If your environment requires PKCS#1 format (e.g. -----BEGIN RSA PRIVATE KEY----- for RSA keys), convert it locally before use:

openssl rsa -in privkey.pem -out privkey-pkcs1.pem

Access Key Requirement

To interact with the Cloud Storage S3-compatible API, this provider requires Google Cloud Storage HMAC credentials.

Required Permissions

The HMAC key must be associated with a service account that has permission to upload objects to the target bucket.

You need to grant the service account at least the following IAM role on the target bucket (or a custom role with equivalent permissions):

roles/storage.objectCreator (or storage.objects.create permission)

Example minimal custom IAM role permissions:

storage.objects.create

For more information on how to manage IAM permissions, please refer to the Google Cloud IAM documentation.