Deploying HTTPS rotator with wildcard support

Assume we're trying to get renewing certificates for my.domain.com and *.my.domain.com

IAM Role

Create an IAM role with permissions like the following (from https://github.com/libdns/route53):

Replace ZONEIDHEREABCDEFG with the zone ID of the route53 zone associated with my.domain.com

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "route53:ListResourceRecordSets",
                "route53:GetChange",
                "route53:ChangeResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::hostedzone/ZONEIDHEREABCDEFG",
                "arn:aws:route53:::change/*"
            ]
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "route53:ListHostedZonesByName",
                "route53:ListHostedZones"
            ],
            "Resource": "*"
        }
    ]
}

EC2 instance

Create a t2.micro (you need at least 1GB ram to build caddy) instance with Ubuntu 20 LTS that accepts incoming SSH (22), HTTPS (443), and HTTP (80) traffic and assign it the above role, making sure the metadata endpoint is accessible.

Route53 config

Associate the A record for my.domain.com with the IP of the EC2 instance

Golang

This and all following steps should occur on the EC2 instance:

Install golang: sudo snap install --classic go

XCaddy

(See: https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148)

Install xcaddy (caddy build tool): go get -u github.com/caddyserver/xcaddy/cmd/xcaddy

Build Caddy with the route53 module: go/bin/xcaddy build --with github.com/caddy-dns/route53

Caddy

Make a file named Caddyfile with the following contents:

*.my.domain.com {
  tls {
    dns route53 {
      max_retries 10
    }
  }
}

my.domain.com {
  redir https://domain.com
}

This will let caddy configure the wildcard cert by changing the route53 records for my.domain.com via the EC2 instance's IAM role

It will also redirect any requests to my.domain.com to domain.com, but you can use any kind of configuration. The important thing is that both top level blocks (the *.my.domain.com block and the my.domain.com block) are present, the TLS config is in the wildcard block, and (possibly) populated.

Once the Caddyfile is in the same directory as the caddy binary, run sudo ./caddy start. You can now safely disconnect your terminal session and caddy will continue to run in the background, but don't! We still have work to do.

Note: Integrating ./caddy start and ./caddy stop into a systemd service is desirable, and left as an exercise to the reader.

Retrieving certificates

The certificates managed by caddy may be found at /root/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory and require root privileges to read. For convenience you may want to symlink this directory somewhere more accessible. Within this directory, there will be a folder for each configured domain -- in our case, 2. One for the wildcard subdomains of my, and one for my itself. In each of these folders will be 3 files: a .json, a .key, and a .crt.

Re-using certificates in Nginx

(See: https://zurgl.com/how-to-set-up-an-nginx-https-website-with-an-ecdsa-certificate-and-get-an-a-rating-on-ssl-labs/)

Nginx needs 2 of these files: the .crt (as the ssl_certificate) and the .key (as the ssl_certificate_key). Note that the generated certificate is an elliptic-curve cert.