Entering .com in Bucket Names Causes SSL Errors

I ran into a simple Amazon S3 naming mistake that created a much more confusing SSL problem: I added .com to an S3 bucket name.

At first, the bucket name looked harmless. It was readable, it looked like the website or domain it belonged to, and Amazon S3 allows periods in some general purpose bucket names. The problem showed up later when the bucket was accessed over HTTPS.

The bucket name started behaving like part of the DNS hostname. Instead of being just a storage container name, the dot made the name look like a domain-style label. That matters because S3 virtual-hosted-style URLs put the bucket name directly into the hostname.

For example, a clean bucket name looks like this:

example-assets.s3.us-east-1.amazonaws.com

A bucket name with .com in it can turn into a hostname like this:

example.com.s3.us-east-1.amazonaws.com

That extra dot changes how TLS certificate matching behaves. The request is still going to S3, but the hostname now has more DNS labels than the normal S3 wildcard certificate can cover.

Why the SSL Error Happens

S3 supports virtual-hosted-style URLs where the bucket name is part of the hostname:

https://bucket-name.s3.region-code.amazonaws.com/key-name

AWS documents an important limitation for this style of request: when using virtual-hosted-style S3 buckets with SSL, the wildcard certificate only matches bucket names that do not contain dots.

So this kind of bucket name is safer for HTTPS access:

example-assets-prod

This kind of bucket name can cause SSL trouble:

example.com-assets-prod

And this is even more clearly domain-like:

example.com

The short version: a period in the bucket name becomes a period in the hostname, and wildcard TLS certificates do not match unlimited hostname depth.

The Fix I Used

The fix was to create a new bucket with a clean name and move the objects into it.

Instead of keeping a dotted name like:

example.com-assets

Use a hyphenated name like:

example-com-assets

or:

example-assets-prod

I used the PowerShell S3 transfer script covered here:

Transfer S3 Contents Between Buckets with PowerShell

That script lets you copy or move objects from one S3 bucket/path to another S3 bucket/path. It can also use different AWS CLI profiles for the source and destination buckets, which is useful if the buckets live in different AWS accounts.

For this problem, the workflow is:

1. Create a new S3 bucket without dots in the name. 2. Start with the script in copy mode. 3. Copy the objects from the old dotted bucket to the new clean bucket. 4. Verify the object counts. 5. Update applications, DNS records, CDN origins, scripts, and documentation to use the new bucket. 6. Only after verification, decide whether to delete or retain the old bucket.

Example Script Settings

In Transfer-S3Contents.ps1, the source bucket can be the old dotted bucket:

$SourceBucket = "example.com-assets"
$DestinationBucket = "example-com-assets"

$SourcePath = "/"
$DestinationPath = "/"

$Mode = "copy"

Start with copy mode. That keeps the old bucket untouched while you test the new bucket.

After you verify the application is working with the new bucket, you can decide whether move mode makes sense:

$Mode = "move"

For most production migrations, I prefer copy mode first. It gives you a rollback path while you update references.

Best Practice: Do Not Use Dots in S3 Bucket Names

My rule after this: do not use dots in S3 bucket names unless there is a very specific static website hosting reason and the HTTPS plan is already understood.

Use hyphens instead:

good: example-com-assets
good: example-assets-prod
good: app-uploads-prod
bad:  example.com-assets
bad:  app.uploads.prod

This avoids SSL surprises, keeps names compatible with virtual-hosted-style URLs, and avoids blocking S3 Transfer Acceleration, which also does not support bucket names with periods.

Other S3 Bucket Naming Best Practices

Keep S3 bucket names boring and predictable for computers, not decorative for people.

• Use lowercase letters, numbers, and hyphens.
• Avoid dots unless you have a very specific reason.
• Do not include .com, .net, or other domain suffixes just to make the bucket look like a website.
• Do not include sensitive information in the bucket name because bucket names can appear in URLs.
• Include an environment label when useful, such as dev, test, stage, or prod.
• Include the workload or purpose, such as uploads, assets, backups, or logs.
• Keep the name globally unique but not overly revealing.
• Avoid reserved suffixes and prefixes listed in the AWS bucket naming rules.
• Remember that a bucket name cannot be changed after creation.
• If you might use S3 Transfer Acceleration, do not use periods.

Example naming pattern:

company-workload-purpose-environment

Examples:

example-web-assets-prod
example-user-uploads-prod
example-backups-stage

Security Best Practices While Fixing It

Renaming a bucket really means creating a new bucket and moving data. Treat that like a small migration.

• Keep S3 Block Public Access enabled unless the bucket intentionally serves public files.
• Use least-privilege IAM credentials for the transfer.
• Prefer IAM roles or temporary credentials where practical.
• Keep server-side encryption enabled.
• Use HTTPS-only bucket policies when the bucket should never be accessed over plain HTTP.
• Enable versioning before high-risk migrations when rollback matters.
• Check bucket policies and object ownership after the transfer.
• Update lifecycle rules, CORS rules, logging, replication, and tags on the new bucket if the old bucket used them.
• Do not delete the old bucket immediately if clients may still be pointing at it.

What to Check After the Move

After copying the objects to the new bucket, check every place that might reference the old dotted bucket:

• Application configuration.
• Environment variables.
• CDN origin settings.
• DNS records.
• Backup scripts.
• Deployment scripts.
• WordPress, CMS, or plugin settings.
• IAM policies that reference the old bucket ARN.
• CORS rules.
• Lifecycle rules.
• Monitoring and logging dashboards.

Also test a real object URL over HTTPS. The important part is not just that the object exists, but that the final HTTPS path works without certificate warnings.

The Lesson

Adding .com to a bucket name can make the name look friendly, but it can make S3 HTTPS access unfriendly.

For S3 buckets, prefer names like:

example-com-assets

not:

example.com-assets

If you already created a dotted bucket and are seeing SSL errors, create a clean replacement bucket and use the S3 transfer script to copy the objects over:

Transfer S3 Contents Between Buckets with PowerShell

References

• Amazon S3 bucket naming rules
• Amazon S3 virtual-hosted-style requests and SSL limitation
• Amazon S3 Transfer Acceleration requirements
• Amazon S3 security best practices