DEV Community: rubendob

Automating SSL with Let’s Encrypt on AWS

rubendob — Thu, 08 Oct 2026 15:21:06 +0000

For quite some time, the SSL certificate for my WordPress site running on AWS worked in a fairly traditional way: I purchased the certificate, renewed it manually once a year, and installed it on the server. It worked, but there was an obvious problem: it depended on periodic manual intervention.

In addition, my architecture had evolved, and this approach to certificate management no longer fitted particularly well.

In this post, we are going to see how to automate an SSL certificate using Let’s Encrypt on AWS.

Initial architecture

The blog is deployed on AWS Elastic Beanstalk, using an EC2 instance in SingleInstance mode.

In front of Elastic Beanstalk, I have a CloudFront distribution:

Internet
   |
   v
CloudFront
   |
   | HTTPS
   v
Elastic Beanstalk
   |
   v
Nginx
   |
   v
WordPress

There are actually two different TLS connections here.

The first one:

Client -> CloudFront

uses a certificate from AWS Certificate Manager (ACM).

That certificate was already fully automated by AWS and did not require any changes.

The second one:

CloudFront -> Elastic Beanstalk / Nginx

used another certificate.

That was the certificate I purchased through DonDominio and that was issued by Sectigo.

Nginx loaded it from:

ssl_certificate     /etc/pki/tls/certs/ssl-bundle.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;

The files were stored in a private S3 bucket, and during the Elastic Beanstalk deployment a hook downloaded both of them:

S3
 |
 v
Elastic Beanstalk prebuild
 |
 v
/etc/pki/tls/certs/
 |
 v
Nginx

The mechanism worked, but every renewal required purchasing the new certificate, downloading it, preparing the certificate chain, uploading it to S3, and deploying it.

The second problem: the EC2 instance is Spot

There was another important detail. The instance used by Elastic Beanstalk is Spot.

This means that the EC2 instance must be treated as ephemeral infrastructure: AWS may replace it.

Therefore, installing Certbot directly on that instance and letting it handle renewals was not a solution I particularly liked.

It could be done, but it would require persisting Certbot's state outside the machine and restoring it whenever the instance was replaced.

I preferred to completely decouple certificate renewal from the EC2 lifecycle.

Goal

The goal was to reach an architecture where:

Let’s Encrypt issued the certificate.
Validation was completely automated.
No permanent AWS credentials were stored in GitHub.
The certificate survived Spot instance replacements.
A renewal automatically updated Nginx.
A new EC2 instance could retrieve the latest available certificate.

The resulting architecture would look like this:

GitHub Actions
      |
      | OIDC
      v
     AWS
      |
      +------> Route53
      |         DNS-01
      |
      +------> Let's Encrypt
      |
      +------> S3
      |         |
      |         +-- ACME state
      |         +-- certificate
      |
      +------> SSM Run Command
                  |
                  v
              EC2 / Nginx

DNS-01 validation with Route53

To issue the certificate, I decided to use the ACME DNS-01 challenge.

The certificate covers:

rubenortiz.es
www.rubenortiz.es

Since the DNS zone is hosted in Route53, Certbot can temporarily create the necessary TXT records to prove to Let’s Encrypt that I control the domain.

The workflow uses:

certbot
+
certbot-dns-route53

This way, I do not need to expose any special URL in WordPress or modify HTTP traffic in order to perform the validation.

GitHub Actions and AWS OIDC

The renewal process runs from GitHub Actions.

Instead of storing an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as secrets, the workflow uses OIDC to temporarily assume an IAM Role.

The flow is:

GitHub Actions
      |
      | OIDC token
      v
AWS STS
      |
      v
IAM Role

That role only receives the permissions required to:

manage the DNS challenge in Route53;
read and write certificates in S3;
locate the active EC2 instance;
execute commands through AWS Systems Manager.

Persisting Certbot state

GitHub Actions runners are also ephemeral.

Each execution starts on a new machine.

Certbot, however, stores important information under:

/etc/letsencrypt

This directory contains ACME accounts, renewal configurations, previous certificates, and other required information.

To avoid losing this state, I decided to store it in S3.

Instead of synchronizing the directory directly, I package it as a tar.gz, because Certbot uses symbolic links between the live and archive directories.

The result is:

s3://mybucket/ssl/acme-state-prod/
    letsencrypt.tar.gz

At the beginning of the workflow:

S3
 |
 v
restore ACME state
 |
 v
Certbot

and after Certbot runs:

Certbot
 |
 v
tar.gz
 |
 v
S3

The active certificate

The certificate that must be consumed by the instances is kept separate from Certbot's internal state:

s3://mybucket/ssl/current/
    fullchain.pem
    privkey.pem

fullchain.pem contains both the domain certificate and the intermediate certificate chain required by Nginx.

The private key is stored as:

privkey.pem

Updating the EC2 instance using SSM

Generating and storing the certificate was only part of the problem.

I still needed the instance running WordPress to actually start using it.

For that, I use AWS Systems Manager Run Command.

GitHub Actions first locates the active Elastic Beanstalk instance using its tags:

aws ec2 describe-instances

It then runs:

aws ssm send-command

using the AWS-managed document:

AWS-RunShellScript

The remote command roughly performs the following operations:

create certificate directory
        |
        v
download fullchain.pem from S3
        |
        v
download privkey.pem from S3
        |
        v
nginx -t
        |
        v
systemctl reload nginx

Before reloading Nginx, the following command is always executed:

nginx -t

If the Nginx configuration is invalid, the process fails before reloading the service.

New Nginx configuration

I also changed the paths used by Nginx to make it clear that these certificates belong to the new mechanism:

ssl_certificate     /etc/pki/tls/certs/letsencrypt/fullchain.pem;
ssl_certificate_key /etc/pki/tls/certs/letsencrypt/privkey.pem;

The first real certificate issuance produced a certificate similar to this:

subject=CN=www.rubenortiz.es
issuer=C=US, O=Let's Encrypt, CN=YE1

DNS:rubenortiz.es
DNS:www.rubenortiz.es

After reloading Nginx, I checked directly against the local Nginx listener:

openssl s_client \
  -connect localhost:443 \
  -servername www.rubenortiz.es

and confirmed that the origin was already serving the Let’s Encrypt certificate.

What happens if AWS replaces the Spot instance?

This was one of the most important parts of the design.

The renewal process does not depend on EC2:

GitHub Actions -> Let's Encrypt -> S3

And S3 acts as the persistent source for the certificate.

The Elastic Beanstalk prebuild hook was also modified to download:

ssl/current/fullchain.pem
ssl/current/privkey.pem

Therefore, if AWS removes the current Spot instance:

Old EC2
    X
    |
    v
New EC2
    |
    v
Elastic Beanstalk prebuild
    |
    v
S3 /ssl/current/
    |
    v
Nginx

the new instance automatically retrieves the current certificate.

Automatic renewal

Finally, the workflow no longer depends on pushes and instead runs on a GitHub Actions cron schedule:

on:
  schedule:
    - cron: "0 6 * * 1"

  workflow_dispatch:

This means it runs every Monday and can also be triggered manually.

Certbot runs with:

--keep-until-expiring

so running the workflow weekly does not mean issuing a new certificate every week.

As long as the current certificate is still valid for long enough, Certbot keeps the existing one.

This is useful because it provides several opportunities to renew the certificate before it reaches its expiration date.

GitHub Actions recipe

In this case, in order to determine which EC2 instance currently exists, I retrieve the information using the EB-related instance tags.

name: Renew Let's Encrypt Certificate

on:
  schedule:
    - cron: "0 6 * * 1"
  workflow_dispatch:

env:
  AWS_REGION: "<AWS_REGION>"
  AWS_ACCOUNT_ID: "<AWS_ACCOUNT_ID>"
  AWS_OIDC_ROLE_NAME: "<OIDC_ROLE_NAME>"

  LETSENCRYPT_EMAIL: "<EMAIL_ADDRESS>"

  CERT_DOMAIN: "www.example.com"
  CERT_APEX_DOMAIN: "example.com"

  CERT_BUCKET: "<PRIVATE_S3_BUCKET>"
  ACME_STATE_KEY: "certificates/acme-state/state.tar.gz"
  CERT_CURRENT_PREFIX: "certificates/current"

  EB_ENV_NAME: "<ELASTIC_BEANSTALK_ENVIRONMENT>"

permissions:
  id-token: write
  contents: read

jobs:
  letsencrypt-production:
    name: Renew production certificate
    runs-on: ubuntu-latest

    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v5
        with:
          role-to-assume: arn:aws:iam::${{ env.AWS_ACCOUNT_ID }}:role/${{ env.AWS_OIDC_ROLE_NAME }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Install Certbot
        run: |
          python -m venv .venv
          .venv/bin/pip install --upgrade pip
          .venv/bin/pip install certbot certbot-dns-route53

      - name: Restore Certbot state from S3
        run: |
          mkdir -p "${{ runner.temp }}/letsencrypt"

          if aws s3 ls \
            "s3://${{ env.CERT_BUCKET }}/${{ env.ACME_STATE_KEY }}" \
            > /dev/null 2>&1; then

            aws s3 cp \
              "s3://${{ env.CERT_BUCKET }}/${{ env.ACME_STATE_KEY }}" \
              "${{ runner.temp }}/letsencrypt.tar.gz"

            tar -xzf "${{ runner.temp }}/letsencrypt.tar.gz" \
              -C "${{ runner.temp }}/letsencrypt"
          fi

      - name: Issue Let's Encrypt certificate
        run: |
          .venv/bin/certbot certonly \
            --dns-route53 \
            --config-dir "${{ runner.temp }}/letsencrypt" \
            --work-dir "${{ runner.temp }}/letsencrypt-work" \
            --logs-dir "${{ runner.temp }}/letsencrypt-logs" \
            --non-interactive \
            --agree-tos \
            --keep-until-expiring \
            --email "${{ env.LETSENCRYPT_EMAIL }}" \
            -d "${{ env.CERT_DOMAIN }}" \
            -d "${{ env.CERT_APEX_DOMAIN }}"

      - name: Validate certificate
        run: |
          openssl x509 \
            -in "${{ runner.temp }}/letsencrypt/live/${{ env.CERT_DOMAIN }}/fullchain.pem" \
            -noout \
            -subject \
            -issuer \
            -dates \
            -ext subjectAltName

      - name: Persist Certbot state to S3
        run: |
          tar -czf "${{ runner.temp }}/letsencrypt.tar.gz" \
            -C "${{ runner.temp }}/letsencrypt" .

          aws s3 cp \
            "${{ runner.temp }}/letsencrypt.tar.gz" \
            "s3://${{ env.CERT_BUCKET }}/${{ env.ACME_STATE_KEY }}"

      - name: Upload active certificate to S3
        run: |
          aws s3 cp \
            "${{ runner.temp }}/letsencrypt/live/${{ env.CERT_DOMAIN }}/fullchain.pem" \
            "s3://${{ env.CERT_BUCKET }}/${{ env.CERT_CURRENT_PREFIX }}/fullchain.pem"

          aws s3 cp \
            "${{ runner.temp }}/letsencrypt/live/${{ env.CERT_DOMAIN }}/privkey.pem" \
            "s3://${{ env.CERT_BUCKET }}/${{ env.CERT_CURRENT_PREFIX }}/privkey.pem"

      - name: Download the new SSL certificate to the EC2 instance
        run: |
          set -euo pipefail

          INSTANCE_ID=$(aws ec2 describe-instances \
            --filters \
              "Name=tag:elasticbeanstalk:environment-name,Values=${{ env.EB_ENV_NAME }}" \
              "Name=instance-state-name,Values=running" \
            --query 'Reservations[].Instances[].InstanceId' \
            --output text)

          if [ -z "$INSTANCE_ID" ]; then
            echo "No running EC2 instance found"
            exit 1
          fi

          echo "EC2 instance found"

          COMMAND_ID=$(aws ssm send-command \
            --instance-ids "$INSTANCE_ID" \
            --document-name "AWS-RunShellScript" \
            --comment "Deploy Let's Encrypt certificate" \
            --parameters 'commands=[
              "mkdir -p /etc/pki/tls/certs/example",
              "aws s3 cp s3://${{ env.CERT_BUCKET }}/${{ env.CERT_CURRENT_PREFIX }}/fullchain.pem /etc/pki/tls/certs/example/fullchain.pem",
              "aws s3 cp s3://${{ env.CERT_BUCKET }}/${{ env.CERT_CURRENT_PREFIX }}/privkey.pem /etc/pki/tls/certs/example/privkey.pem",
              "chmod 600 /etc/pki/tls/certs/example/privkey.pem",
              "nginx -t",
              "systemctl reload nginx",
              "openssl x509 -in /etc/pki/tls/certs/example/fullchain.pem -noout -subject -issuer -dates"
            ]' \
            --query 'Command.CommandId' \
            --output text)

          echo "SSM command submitted"

          set +e

          aws ssm wait command-executed \
            --command-id "$COMMAND_ID" \
            --instance-id "$INSTANCE_ID"

          WAIT_EXIT_CODE=$?

          set -e

          echo "SSM command result:"

          aws ssm get-command-invocation \
            --command-id "$COMMAND_ID" \
            --instance-id "$INSTANCE_ID" \
            --query '{
              Status:Status,
              StandardOutput:StandardOutputContent,
              StandardError:StandardErrorContent
            }'

          if [ "$WAIT_EXIT_CODE" -ne 0 ]; then
            echo "SSM command failed or timed out"
            exit 1
          fi

Final architecture

The final result looks like this:

                     +------------------+
                     |  GitHub Actions  |
                     |   weekly cron    |
                     +--------+---------+
                              |
                             OIDC
                              |
                              v
                     +------------------+
                     |       AWS        |
                     +------------------+
                         |          |
                         |          |
                  Route53 DNS-01    |
                         |          |
                         v          |
                  Let's Encrypt     |
                         |          |
                         +----+-----+
                              |
                              v
                    +--------------------+
                    |         S3         |
                    |                    |
                    | acme-state-prod/   |
                    | current/           |
                    +---------+----------+
                              |
                             SSM
                              |
                              v
                     +------------------+
                     | Elastic Beanstalk|
                     |      EC2 Spot    |
                     +--------+---------+
                              |
                              v
                            Nginx
                              |
                              v
                          WordPress

CloudFront continues to use ACM for the public-facing certificate:

User
  |
  | HTTPS / ACM
  |
CloudFront
  |
  | HTTPS / Let's Encrypt
  |
Nginx

Result

With this change, I removed the manual renewal of a certificate purchased from an external provider from the normal operational workflow.

Now:

Let’s Encrypt issues and renews the certificate.
Route53 automatically handles the ACME challenge.
GitHub Actions runs the process periodically.
OIDC avoids permanent AWS credentials.
S3 stores both the certificate and the ACME state.
SSM updates the active EC2 instance.
Nginx validates its configuration before being reloaded.
A new Spot instance can rebuild itself using the certificate stored in S3.

And perhaps most importantly, certificate management no longer depends on the lifetime of a specific machine or on me remembering once a year that the certificate needs to be renewed.

Terraform: Checksum Mismatch Between S3 and DynamoDB

rubendob — Thu, 08 Oct 2026 09:47:09 +0000

Recently, I ran into an interesting issue with a Terraform remote backend.

Out of nowhere, every Terraform operation (plan, refresh, or apply) started failing with an error related to the remote state.

Terraform was reporting a checksum mismatch between the state stored in S3 and the value stored in DynamoDB.

The error looked like this:

Error: state data in S3 does not have the expected content

The checksum calculated for the state stored in S3 does not match the checksum
stored in DynamoDB.

Calculated checksum: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Stored checksum:     YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

The Problem

In this setup, Terraform was using:

An S3 bucket to store the terraform.tfstate file.
A DynamoDB table to manage locking and metadata associated with the remote state.

When Terraform accesses the backend, it:

Reads the state stored in S3.
Calculates its checksum.
Compares that value with the Digest stored in DynamoDB.

In our case, those two values did not match.

Because of this inconsistency, Terraform refused to continue in order to avoid working with a state that could potentially be corrupted or outdated.

Initial Checks

Before changing anything, we went through a few basic checks:

Confirm that no terraform apply operation was currently running.
Confirm that no CI/CD pipeline was using the same remote state.
Reproduce the issue both locally and from the CI/CD pipelines.

Since the same error appeared regardless of where Terraform was executed, we could quickly rule out a problem with the local machine or the pipeline configuration.

Finding the Mismatch

The next step was to inspect the DynamoDB table associated with the remote backend.

Using the AWS CLI, we searched for the entry related to the affected state:

aws dynamodb scan \
  --table-name <lock-table>

Among the results, we found an entry similar to this:

{
  "LockID": {
    "S": "<state-path>-md5"
  },
  "Digest": {
    "S": "old-value"
  }
}

The value stored in Digest matched exactly the checksum Terraform was reporting as incorrect.

This confirmed that the current state stored in S3 and the digest registered in DynamoDB were out of sync.

The Fix

Terraform was already telling us which checksum it expected:

Calculated checksum: correct-value
Stored checksum:     old-value

After verifying that the state file stored in S3 was valid, and confirming that no Terraform operation was currently running, we manually updated the Digest field in DynamoDB so that it matched the checksum calculated by Terraform.

For example:

aws dynamodb update-item \
  --table-name <lock-table> \
  --key '{"LockID":{"S":"<state-path>-md5"}}' \
  --update-expression "SET Digest = :d" \
  --expression-attribute-values '{":d":{"S":"correct-value"}}'

This type of manual change should be done carefully.

You should not update the Digest just to make the error disappear. First, make sure that the state stored in S3 is the correct one and that there are no concurrent Terraform operations running against the same backend.

Result

After updating the Digest, we ran:

terraform plan

Terraform was able to access the remote backend again, and the plan completed successfully.

We did not need to:

Recreate the state.
Restore a previous state version.
Modify the Terraform code.
Recreate any infrastructure resources.

The issue was simply a mismatch between the checksum stored in DynamoDB and the actual contents of the state file stored in S3.

Lessons Learned

When you see an error like:

state data in S3 does not have the expected content

it is easy to immediately assume that the terraform.tfstate file is corrupted.

However, that is not always the case.

The state stored in S3 may be perfectly valid, while the inconsistency exists only in the Digest value stored in DynamoDB.

Before making any changes, I recommend checking the following:

Confirm that no Terraform executions are currently running.
Confirm that no CI/CD pipeline is using the same backend.
Verify the state stored in S3.
Inspect the corresponding entry in DynamoDB.
Compare Terraform's Calculated checksum with the Stored checksum.

Only after completing those checks should you consider manually correcting the Digest.

In this case, a few minutes spent understanding how the remote backend works saved us from wasting much more time debugging Terraform code that was not actually the problem.

Protecting Credentials in Claude Code

rubendob — Wed, 07 Oct 2026 14:23:50 +0000

Protecting Credentials in Claude Code

There is a problem nobody really tells you about.

If you use Claude Code for development, there is something you may not realize: it stores a complete history of your conversations as plain text on your machine. Depending on how you have used it, you may need to review how you handle credentials sooner rather than later.

~/.claude/history.jsonl
~/.claude/file-history/
~/.claude/projects/

On top of that, everything you type into the chat is sent to Anthropic's servers for processing.

That is how the service works — it is not a secret — but it is also something you may not think about while you are in the middle of a coding session.

That is why knowing how to protect credentials when using Claude Code is critical. Or, at the very least, understanding the security practices you should follow.

How to protect credentials in Claude Code

Before looking at detection and remediation, it is useful to understand which configuration files Claude Code uses and where they live.

There are two main types.

~/.claude/settings.json — your personal configuration. It can contain permissions, MCP servers and environment configuration. This is the file you normally edit yourself.

/Library/Application Support/ClaudeCode/managed-settings.json — managed configuration for corporate environments. Administrators can use it to enforce security policies across an organization through MDM.

If you work independently, this file probably does not exist on your machine.

Both files can contain sensitive information if they are not configured carefully — especially settings.json, where it is easy to accidentally end up with hardcoded credentials.

Step 1: Detection

I started by scanning these files for credentials.

I looked for common patterns such as AWS Access Key prefixes (AKIA, AKAR, etc.), GitHub tokens (ghp_) and generic long-format keys.

The result was not particularly surprising.

When configuring connectors or integrations with certain providers, sensitive values can end up stored locally in files used by Claude.

The bigger problem is that the information may not stay there. If you paste credentials into a conversation, that information is also sent to the model provider.

That is the part that should make us think more carefully about how we use coding assistants.

And I do not think this topic is discussed enough.

The rule I ended up with: treat Claude like pair programming over a video call with someone outside your company. You would not show them your keys on screen.

Step 2: Cleanup

The first thing I did was revoke every credential that might have been exposed.

If a key has appeared in plain text, I prefer to consider it compromised even if there is no evidence that somebody actually used it.

Clear the chat history:

~/.claude/history.jsonl

Remove backups of files edited by Claude:

rm -rf ~/.claude/file-history/*

Clear conversations stored by project:

find ~/.claude/projects/ -name "*.jsonl" -exec truncate -s 0 {} \;

Then review the configuration file.

If there are tokens there, remove them:

~/.claude/settings.json

Step 3: Reconfigure using better security practices

Once the credentials had been cleaned up and revoked, the goal was to configure everything again without allowing secret values to appear directly in the chat or in Claude configuration files.

Use a GitHub token with minimum privileges

When configuring a GitHub token for Claude Code, do not enable every permission just because it is convenient.

Apply the principle of least privilege and grant only the permissions you actually need.

For example, when using a classic token with private repositories:

Scope	Purpose
repo	Read and write code, pull requests, issues and commits
workflow	View and modify GitHub Actions workflows
read:org	Access private organization repositories
read:user	User identification

What you should avoid enabling unnecessarily: admin:org, delete_repo, admin:repo_hook, write:org, or other administrative scopes.

The idea is the same as with any other credential.

If a token is compromised, it should only be able to perform the exact operations you intended.

The more permissions it has, the larger the blast radius.

If your use case supports them, fine-grained tokens are usually a better option because they allow you to restrict access to specific repositories instead of granting access to the entire account.

The same principle applies to every other kind of token or key.

Use 1Password CLI as the source of truth

One option is to use 1Password.

It provides a CLI that can inject secrets directly into your shell environment without requiring you to store the actual values in your configuration files.

Once everything is configured correctly, you will see something similar when Claude needs access to a specific item.

Install the CLI:

brew install 1password-cli

Check the account status:

op account list

If you use SSO, Okta or another identity provider, there is an additional consideration.

Create the item in 1Password:

Create a new item of type API Credential in the vault you use.
Give it an easy-to-reference name, for example GitHub PAT.
Store the token in the credential field.
If your Business account uses SSO, standard CLI authentication may not work directly.
Open the 1Password desktop application.
Go to Settings → Developer → Connect with 1Password CLI.
Enable it.

The CLI will then authenticate through the desktop application, which already has your SSO session.

No master password needs to be placed in scripts or configuration files.

Then update your .zshrc:

export GITHUB_PERSONAL_ACCESS_TOKEN=$(op read "op://MyVault/GitHub_PAT/credential" --no-newline)
export GITHUB_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN

Verify the environment variable without printing the complete secret:

echo $GITHUB_TOKEN | cut -c1-4

# Reload the shell configuration
source ~/.zshrc

Before — the actual value can end up in .zsh_history, and Claude may be able to read it:

export GITHUB_TOKEN=ghp_abc123xyz…

Now — the value itself never appears directly in the configuration.

Claude only uses $GITHUB_TOKEN from the environment.

The actual secret stays in 1Password, and you never need to paste it into the chat.

The MCP configuration can then inherit the variable from the environment instead of hardcoding it:

"github": {
  "type": "stdio",
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-e",
    "GITHUB_PERSONAL_ACCESS_TOKEN",
    "ghcr.io/github/github-mcp-server"
  ],
  "env": {}
}

Finally, verify that Claude can still operate correctly.

For example:

list my GitHub repositories

If the MCP server can still return your repositories, the flow works end to end.

Step 3.1: Rotate credentials

If a key has been exposed, even briefly, rotate it.

With AWS and GitHub this is usually quick, and rotating credentials reduces the amount of time an exposed key remains useful.

What this does not solve

If you paste a token directly into the chat, it is still sent to Anthropic.

1Password protects you from accidental exposure through configuration files or environment setup.

It does not protect you from secrets that you deliberately paste into a conversation.

The most important security control is still your own workflow and habits.

5. Beyond credentials: securing Claude Code itself

Managing secrets correctly is only part of the problem.

Claude Code also has a permissions and configuration system that is worth hardening.

5.1 Limit MCP servers

Do not enable every MCP server by default.

Only enable the ones you actually need and explicitly disable the others.

This can be configured in managed-settings.json:

"enabledMcpjsonServers": ["github"],
"disabledMcpjsonServers": ["filesystem"]

5.2 Configure permissions carefully

The remaining examples belong in settings.json.

Claude Code provides three permission levels:

Allow — only for operations you consider completely harmless
Ask — operations with potential impact, such as git push or docker run
Deny — operations that should always be blocked

The important principle is the same: minimum privilege.

Before:

{
  "permissions": {
    "allow": [
      "Bash(curl:*)",
      "Bash(docker:*)"
    ]
  }
}

After:

{
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(docker:*)"
    ]
  }
}

5.3 Restrict access to sensitive directories

You can also explicitly deny access to paths and files that may contain sensitive information:

{
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(rm -rf:*)",
      "Read(~/.ssh/*)",
      "Read(~/.aws/*)",
      "Read(**/*.pem)",
      "Read(**/.env*)"
    ]
  }
}

5.4 Automatic cleanup

You can also configure cleanup of historical information:

{
  "cleanupPeriodDays": 7
}

4. Lessons learned

Treat Claude Code like a junior developer with root access

Claude Code can dramatically improve productivity.

But if it is not configured properly, it can also:

expose credentials;
corrupt repositories;
open the door to unauthorized access.

AI coding tools are extremely useful.

They should simply be treated with the same security discipline as any other tool that has access to your development environment.

Have you run into something similar? Do you use another approach for managing credentials securely? Let me know in the comments.

How I Reduced WordPress LCP from 7.7s to 2.5s

rubendob — Wed, 07 Oct 2026 08:55:35 +0000

A website can feel fast when you open it from a desktop computer with a good connection, but the experience can be very different on a mid-range mobile device using 4G.

That was exactly what happened with my WordPress site.

During a performance analysis, I found a particularly bad metric:

LCP: 7.7s
TBT: 64ms
CLS: 0.01

The Largest Contentful Paint was 7.7 seconds.

My target was clear:

7.7s → ≤ 2.5s

Rather than installing another WordPress performance plugin and hoping for the best, I decided to investigate the complete request path:

Browser
   |
   v
CloudFront
   |
   v
Nginx
   |
   v
WordPress

This led to several interesting findings involving images, CloudFront compression, Nginx configuration, JavaScript, caching and fonts.

1. Optimizing the background image

One of the first large resources I found was the background image:

fondo.jpg
394675 bytes

It was a 1920x1080 JPG weighing around 395 KB.

The first optimization was straightforward: convert it to WebP.

The result:

BEFORE
fondo.jpg
~395 KB

AFTER
fondo.webp
~187 KB

Almost half the amount of data for essentially the same visual result.

Safari confirmed the new asset was being served correctly:

Content-Type: image/webp
Content-Length: 187212

This alone wasn't going to explain a 7.7-second LCP, but it was an obvious improvement.

2. Discovering that CloudFront wasn't compressing the main page

The next thing I wanted to understand was how much HTML was actually being transferred.

I tested it with curl:

curl -sS \
  -H 'Accept-Encoding: br, gzip' \
  -D /tmp/before-headers.txt \
  -o /dev/null \
  -w 'download=%{size_download} bytes\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.example.com/

The result was approximately:

download=108015 bytes
ttfb=0.399917 s
total=0.518430 s

Around 108 KB of HTML.

More importantly, the response didn't contain:

Content-Encoding: gzip

or:

Content-Encoding: br

The HTML was being transferred without compression.

Checking CloudFront

My specific CloudFront cache behaviors already had compression enabled:

ordered_cache_behavior {
  path_pattern = "/wp-content/uploads/*"

  ...

  compress = true
}

But the main behavior didn't.

I added:

default_cache_behavior {
  ...

  compress               = true
  viewer_protocol_policy = "redirect-to-https"

  min_ttl     = 0
  default_ttl = 3600
  max_ttl     = 86400
}

After applying the Terraform change, I tested an Autoptimize CSS file.

Before compression:

~272 KB

After compression:

content-type: text/css
content-encoding: gzip
x-cache: Miss from cloudfront

download=45685 bytes

So:

CSS
~272 KB → ~46 KB

That's roughly an 83% reduction.

CloudFront compression was working.

But there was still a problem.

The HTML wasn't being compressed.

3. The problem was also in Nginx

To isolate CloudFront, I tested the Elastic Beanstalk origin directly.

The response contained:

Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked

But still no:

Content-Encoding: gzip

That meant the origin itself wasn't compressing dynamic WordPress HTML.

I added the usual Nginx gzip configuration:

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 1024;

gzip_types
    text/plain
    text/css
    application/json
    application/javascript
    application/x-javascript
    text/xml
    application/xml
    application/xml+rss
    text/javascript
    image/svg+xml;

But surprisingly, HTML was still not compressed.

That's when things got interesting.

4. Gzip was enabled... only for HTTP

I inspected the effective Nginx configuration:

sudo nginx -T 2>&1 | grep -nE 'listen .*443|listen .*80|server_name'

I found separate server blocks:

listen 80 default_server;

listen 443 ssl;
server_name www.example.com;

Then I checked where my gzip configuration was located.

It was inside:

server {
    listen 80 default_server;

    ...

    gzip on;
    gzip_vary on;
    gzip_proxied any;

    ...
}

That was the problem.

My gzip configuration belonged only to the HTTP server block listening on port 80.

The actual application traffic was arriving through a different HTTPS server:

server {
    listen 443 ssl;
    server_name www.example.com;

    ...
}

The HTTPS server wasn't inheriting the gzip configuration.

The fix

I moved the gzip configuration to:

.platform/nginx/conf.d/gzip.conf

This placed it inside Nginx's global http {} context.

Conceptually:

http
 |
 +-- gzip on
 |
 +-- server :80
 |
 +-- server :443

Both HTTP and HTTPS could now inherit the configuration.

Then:

sudo nginx -t
sudo systemctl reload nginx

5. Verifying gzip at the origin

I tested the origin again.

This time:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Vary: Accept-Encoding
Content-Encoding: gzip

And the transferred HTML size changed dramatically:

BEFORE
~108 KB

AFTER
~22 KB

Approximately an 80% reduction.

This was one of the most useful discoveries during the whole investigation.

Having:

gzip on;

somewhere in your Nginx configuration does not necessarily mean gzip is enabled for the traffic your users are actually receiving.

Context matters.

6. Testing the full CloudFront path

Now I could test the complete chain again:

Browser
   |
   | Accept-Encoding: gzip
   v
CloudFront
   |
   v
Nginx
   |
   | gzip
   v
WordPress

The first request returned:

content-encoding: gzip
vary: Accept-Encoding
x-cache: Miss from cloudfront

download=21769 bytes

And a second request:

content-encoding: gzip
vary: Accept-Encoding
x-cache: Hit from cloudfront
age: 8

download=21769 bytes

The full path was finally behaving as expected.

7. Deferring jQuery

Lighthouse also identified jquery.min.js as a render-blocking resource.

The interesting part wasn't its approximately 31 KB size.

The problem was that the browser needed to download and process it before continuing the initial render.

I was already using Autoptimize with its option to defer individual JavaScript files, but jQuery was explicitly excluded.

After removing only that exclusion and clearing the Autoptimize cache, both jquery-core and jquery-migrate started loading with:

defer

without breaking the site.

Lighthouse then stopped listing jQuery under Render-blocking requests.

The measurements moved approximately from:

FCP         1.7s → 1.5s
LCP         3.6s → 3.4s
Speed Index 3.5s → 3.3s

The improvement was relatively small and could partially fall within normal Lighthouse run-to-run variation.

The important result was that JavaScript had been removed from the critical rendering path without breaking dependencies.

8. Caching hashed assets for one year

I also found that Autoptimize-generated files were cached for only 30 days:

Cache-Control: max-age=2592000

A typical generated file looked like:

autoptimize_b7e1ec6b8133370482e43a1431d3a757.css

These assets contain a hash in their filename.

When the content changes, their URL changes as well.

That means they are excellent candidates for long-lived browser caching.

I added a specific Nginx rule for:

/wp-content/cache/autoptimize/

using:

expires 1y;

The response then became:

Cache-Control: max-age=31536000

This improves repeat visits by avoiding unnecessary downloads of immutable assets.

9. Changing `font-display: block` to `swap`

One of the final Lighthouse findings involved the Flatsome icon font.

It was using:

font-display: block;

With block, the browser may wait for the font before displaying content that depends on it.

I changed the behavior to:

font-display: swap;

using a customization in the WordPress child theme instead of modifying the parent theme directly.

After deploying the change, my measurements went from:

LCP: 3.4s

to:

LCP: 2.5s

FCP remained around:

1.5s

TBT:

0ms

and CLS:

0.007

A single Lighthouse execution doesn't prove that the entire 0.9-second improvement was caused by this change alone, but the result was encouraging.

Most importantly, the LCP finally reached my original target.

Final results

Some of the biggest improvements were easy to quantify:

Resource	Before	After
Background image	~395 KB JPG	~187 KB WebP
Home HTML	~108 KB	~22 KB gzip
Autoptimize CSS	~272 KB	~46 KB gzip

For the HTML:

108015 bytes
     ↓
~21788 bytes

Around 80% less transferred data.

For CSS:

271802 bytes
     ↓
45685 bytes

Around an 83% reduction.

And, most importantly:

Initial LCP
7.7s

      ↓

Final Lighthouse LCP
2.5s

A note about TTFB

During testing I saw one request with a TTFB above six seconds.

It would have been easy to conclude that the origin server had a serious performance problem.

Instead, I repeated several forced cache-miss requests:

MISS 1  TTFB=1.648s
MISS 2  TTFB=0.831s
MISS 3  TTFB=0.858s
MISS 4  TTFB=0.674s
MISS 5  TTFB=0.739s

The six-second request was clearly an outlier rather than normal server behavior.

This is a useful reminder when doing performance work:

don't optimize based on a single measurement.

Repeat your tests.

What I learned

My initial goal was simply to improve a very poor LCP score.

But the most interesting part of the investigation was that there wasn't one magical fix.

The final improvement came from several layers:

Heavy JPG
    ↓
WebP

Uncompressed responses
    ↓
gzip

gzip in the wrong Nginx context
    ↓
global http{} configuration

Render-blocking jQuery
    ↓
defer

Short-lived hashed assets
    ↓
1-year cache

font-display: block
    ↓
font-display: swap

One detail was particularly easy to miss:

Enabling gzip in Nginx doesn't necessarily mean every virtual host is using it.

In my case, gzip was configured inside the port 80 server block while the real traffic was being served through the independent HTTPS server on port 443.

Moving gzip to the global configuration fixed the issue.

Performance work often ends up being less about installing another optimization plugin and more about understanding where the browser is actually spending its time.

The improvements were also reflected in external performance tools. In Wakaris, the site's performance score increased from 33% to 83%, while accessibility improved from 78% to 94%, SEO positioning from 78% to 89%, presence from 33% to 100%, and security from 63% to 82%.

The changes were also clearly visible in Google PageSpeed Insights, where the desktop version reached a 99/100 performance score, while the mobile version also showed a well-optimized result. These measurements confirmed that the work was not only reducing individual resource sizes, but improving the overall performance and quality of the site.

Originally published in Spanish on RubenOrtiz.es:

Read the original Spanish article

DEV Community: rubendob

Automating SSL with Let’s Encrypt on AWS

Initial architecture

The second problem: the EC2 instance is Spot

Goal

DNS-01 validation with Route53

GitHub Actions and AWS OIDC

Persisting Certbot state

The active certificate

Updating the EC2 instance using SSM

New Nginx configuration

What happens if AWS replaces the Spot instance?

Automatic renewal

GitHub Actions recipe

Final architecture

Result

Links

Terraform: Checksum Mismatch Between S3 and DynamoDB

The Problem

Initial Checks

Finding the Mismatch

The Fix

Result

Lessons Learned

Links

Protecting Credentials in Claude Code

Protecting Credentials in Claude Code

How to protect credentials in Claude Code

Step 1: Detection

Step 2: Cleanup

Step 3: Reconfigure using better security practices

Use a GitHub token with minimum privileges

Use 1Password CLI as the source of truth

Step 3.1: Rotate credentials

What this does not solve

5. Beyond credentials: securing Claude Code itself

5.1 Limit MCP servers

5.2 Configure permissions carefully

5.3 Restrict access to sensitive directories

5.4 Automatic cleanup

4. Lessons learned

Treat Claude Code like a junior developer with root access

Links

How I Reduced WordPress LCP from 7.7s to 2.5s

1. Optimizing the background image

2. Discovering that CloudFront wasn't compressing the main page

Checking CloudFront

3. The problem was also in Nginx

4. Gzip was enabled... only for HTTP

The fix

5. Verifying gzip at the origin

6. Testing the full CloudFront path

7. Deferring jQuery

8. Caching hashed assets for one year

9. Changing font-display: block to swap

Final results

A note about TTFB

What I learned

9. Changing `font-display: block` to `swap`