GithubHelp home page GithubHelp logo

route53's Introduction

Route53 module for Caddy

This package contains a DNS provider module for Caddy. It can be used to manage DNS records in Route53 Hosted zones.

Caddy module name

dns.providers.route53

Authenticating

See the associated README in the libdns package for important information about credentials and an IAM policy example.

Building

To compile this Caddy module, follow the steps describe at the Caddy Build from Source instructions and import the github.com/caddy-dns/route53 plugin

Config examples

This module supports all the credential configuration methods described in the AWS Developer Guide, such as Environment Variables, Shared configuration files, the AWS Credentials file located in .aws/credentials, and Static Credentials. You may also pass in static credentials directly (or via caddy's configuration).

To use this module for the ACME DNS challenge, configure the ACME issuer in your Caddy JSON like so:

{
  "module": "acme",
  "challenges": {
    "dns": {
      "provider": {
        "name": "route53",
        "max_retries": 10, // optional
        "aws_profile": "real-profile", // optional
        "region": "us-east-1", // optional
        "access_key_id": "AKI...", // optional
        "secret_access_key": "wJa...", // optional
        "token": "TOKEN...", // optional
      }
    }
  }
}

or with the Caddyfile:

tls {
  dns route53 {
    max_retries 10 // optional
    aws_profile "real-profile" // optional
    access_key_id "AKI..." // optional
    secret_access_key "wJa..." // optional
    token "TOKEN..." // optional
    region "us-east-1" // optional
  }
}

route53's People

Contributors

0xflotus avatar aymanbagabas avatar danlsgiga avatar dependabot[bot] avatar francislavoie avatar phoenixpeca avatar rayjlinden avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

route53's Issues

Module not working or I'm dumb

Hello Guys, how are you?
We are facing a problem with the Route53 module.
After install the module and configuring it, we are receiving the following error message when we run the system status caddy:

Our configs / Code inside the Caddyfile:

*.example.com {
tls {
dns route53 {
max_retries 10
}
}
reverse_proxy {
to http://target.example.com
}
}

Then we reload the service (or even reboot the machine) and now we receive the following error message after sudo systemctl status caddy:

Jul 19 20:49:29 caddy[1827]: {"level":"error","ts":1658263769.5214586,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":".domain.com","issuer":"acme-staging-v02.api.letsencrypt.org-directory","error":"[.domain.com] solving challenges: presenting for challenge: adding temporary record for zone domain.com.: operation error Route 53: ListHostedZonesByName, failed to sign request: failed to retrieve credentials: static credentials are empty (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/61399564/3266863684) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}

Ps. I'm opening an issue because it used to work in our lab and this is a new environment and I don't know if the new version has any issue or (probably) I'm doing something wrong.

Thanks,
Rodolfo

[bug]: Deprecated AWSProfile field on config

It seems like that github.com/libdns/route53 which uses github.com/aws/aws-sdk-go/service/route53 (*r53.Route53) has removed the AWSProfile field so copying the example from README doesn't work anymore.

Documentation: IAM roles required

The documentation should probably mention the minimum IAM roles needed for route53 for this to work. The following worked for me (single hosted zone, wildcard subdomains) although it could surely be improved with eg conditional matching policies.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "route53:ChangeResourceRecordSets",
            "Resource": "arn:aws:route53:::hostedzone/ZZZZZZZZ"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "route53:ListHostedZonesByName",
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "route53:ListResourceRecordSets",
            "Resource": "arn:aws:route53:::hostedzone/ZZZZZZZZ"
        }
    ]
}

(Replace ZZZZZZZZ with your zone id)

Malformed TXT record (zone wrongly duplicated as part of subdomain)

We're using the Route53 DNS module to satisfy ACME challenges but are hitting a strange bug. For some reason, the TXT record created is malformed and wrongly duplicates the main zone as part of the subdomain (causing an endless verification timeout loop).

We are running caddy in a container on an EC2 machine.

Contents of Docker file for Caddy:

FROM caddy:2.3.0-builder-alpine AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/route53

FROM caddy:2.3.0-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

COPY Caddyfile /etc/caddy/Caddyfile

Contents of /etc/caddy/Caddyfile in the running container (real FQDN is different but have kept everything else the same)

www.mydomain.com
reverse_proxy 127.0.0.1:3000
tls {
  dns route53 {
    max_retries 10
    aws_profile ""
  }
}

This results in the following TXT record being created in Route53: _acme-challenge.www.mydomain.com.mydomain.com. (note the zone is duplicated).

The challenge verification then times out since it looks for _acme-challenge.www.mydomain.com. (which is never created).

If we manually create the correct TXT record (via the Route53 web console) and use the value from the wrongly auto-created TXT record, verification passes. The wrongly created TXT record is then automatically cleaned up, and the manually created one stays present.

Here's a log capture showing this (with s/realFQDN/www.mydomain.com/g to keep it generic):

root@ip-10-0-0-17:~# docker logs caddy
{"level":"info","ts":1631101549.0512967,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1631101549.0558064,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
{"level":"info","ts":1631101549.0587218,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1631101549.0589776,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1631101549.06152,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0002e12d0"}
{"level":"info","ts":1631101549.0621595,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["www.mydomain.com"]}
{"level":"info","ts":1631101549.0632653,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1631101549.0637987,"msg":"serving initial configuration"}
{"level":"info","ts":1631101549.0639155,"logger":"tls","msg":"cleaned up storage units"}
{"level":"info","ts":1631101549.0643346,"logger":"tls.obtain","msg":"acquiring lock","identifier":"www.mydomain.com"}
{"level":"info","ts":1631101549.0663319,"logger":"tls.obtain","msg":"lock acquired","identifier":"www.mydomain.com"}
{"level":"info","ts":1631101549.981814,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["www.mydomain.com"]}
{"level":"info","ts":1631101549.9818606,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["www.mydomain.com"]}
{"level":"info","ts":1631101550.898957,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.mydomain.com","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1631101551.5204628,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"www.mydomain.com","challenge_type":"dns-01","error":"no memory of presenting a DNS record for www.mydomain.com (probably OK if presenting failed)"}
{"level":"error","ts":1631101551.7166426,"logger":"tls.obtain","msg":"will retry","error":"[www.mydomain.com] Obtain: [www.mydomain.com] solving challenges: presenting for challenge: adding temporary record for zone mydomain.com.: InvalidChangeBatch: InvalidChangeBatch: [Tried to create resource record set [name='_acme-challenge.www.mydomain.com.mydomain.com.', type='TXT'] but it already exists]\n\tstatus code: 400, request id: 4d3c4fea-681a-4c09-8965-7fd2fb111dfd (order=https://acme-v02.api.letsencrypt.org/acme/order/192612760/22920570770) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":2.650090972,"max_duration":2592000}
{"level":"info","ts":1631101612.867892,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.mydomain.com","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1631101613.3855636,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"www.mydomain.com","challenge_type":"dns-01","error":"no memory of presenting a DNS record for www.mydomain.com (probably OK if presenting failed)"}
{"level":"error","ts":1631101613.5276074,"logger":"tls.obtain","msg":"will retry","error":"[www.mydomain.com] Obtain: [www.mydomain.com] solving challenges: presenting for challenge: adding temporary record for zone mydomain.com.: InvalidChangeBatch: InvalidChangeBatch: [Tried to create resource record set [name='_acme-challenge.www.mydomain.com.mydomain.com.', type='TXT'] but it already exists]\n\tstatus code: 400, request id: 8cfb3e00-9657-453d-b867-5e2193a54623 (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/25931808/488611558) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":64.461055717,"max_duration":2592000}
{"level":"info","ts":1631101735.2945147,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.mydomain.com","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
{"level":"info","ts":1631101876.6568108,"logger":"tls.issuance.acme.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/25931808/488621888"}
{"level":"info","ts":1631101878.9950337,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":1,"first_url":"https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa47a21093c8f08654bbf8d740f229b28fdd"}
{"level":"info","ts":1631101878.9953816,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["www.mydomain.com"]}
{"level":"info","ts":1631101878.9954185,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["www.mydomain.com"]}
{"level":"info","ts":1631101880.0348005,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"www.mydomain.com","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"info","ts":1631102028.8770761,"logger":"tls.issuance.acme.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme-v02.api.letsencrypt.org/acme/order/192612760/22921420555"}
{"level":"info","ts":1631102029.8177788,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https://acme-v02.api.letsencrypt.org/acme/cert/0412ef9b7a225e28e353c35d0a1119f972cc"}
{"level":"info","ts":1631102029.818293,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"www.mydomain.com"}
{"level":"info","ts":1631102029.8183181,"logger":"tls.obtain","msg":"releasing lock","identifier":"www.mydomain.com"}

Cannot build v1.0.0

My main.go:

package main

import (
caddycmd "github.com/caddyserver/caddy/v2/cmd"

    // plug in Caddy modules here
    _ "github.com/caddyserver/caddy/v2/modules/standard"
    _ "github.com/caddy-dns/route53"

)

func main() {
caddycmd.Main()
}

go build results in:

go: finding module for package github.com/caddyserver/caddy/v2/modules/standard
go: finding module for package github.com/caddyserver/caddy/v2/cmd
go: finding module for package github.com/caddy-dns/route53
go: found github.com/caddy-dns/route53 in github.com/caddy-dns/route53 v1.0.0
go: found github.com/caddyserver/caddy/v2/cmd in github.com/caddyserver/caddy/v2 v2.0.0
go: github.com/caddy-dns/[email protected] requires
github.com/libdns/[email protected]: invalid version: unknown revision 000000000000

Even though it should be fixed in 7a9c68f it is still looking for the wrong version.

What is going wrong here?

Cannot get certificate with latest Rout53 plugin using docker

Hi, this problem started (iguess) on release 1.3

If I,m using a previous version of the plugin, it works. I get this error:
"type":"urn:ietf:params:acme:error:malformed","status":405,"detail":"The request message was malformed"

I get this error from the logs:
caddyaws2023 | {"level":"error","ts":1675007436.1783702,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"HOST.DOMAINEXEMPLE.com","issuer":"acme.zerossl.com-v2-DV90","error":"[HOST.DOMAINEXEMPLE.com] solving challenges: presenting for challenge: adding temporary record for zone \"DOMAINEXAMPLE.com.\": Error unquoting TXT/SPF record: invalid syntax (order=https://acme.zerossl.com/v2/DV90/order/dkpx3lDTGufoX8eT6p3Tvw) (ca=https://acme.zerossl.com/v2/DV90)"}
Then, I let the whole configuration intact and just replace the custom caddy file for the older version and I get a Zerossl certificate.
Still it seems it to fail getting the letsencrypt one but I still get a Zerossl cert at least.:

caddyaws2023  | {"level":"error","ts":1675008197.5518668,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"testicule.example.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: NXDOMAIN looking up TXT for _acme-challenge.testicule.example.com - check that a DNS record exists for this domain"}
caddyaws2023  | {"level":"info","ts":1675008197.552192,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["testicule.example.com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"[email protected]"}
caddyaws2023  | {"level":"info","ts":1675008197.5522494,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["testicule.example.com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"[email protected]"}
caddyaws2023  | {"level":"info","ts":1675008212.2545922,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"testicule.example.com","challenge_type":"dns-01","ca":"https://acme.zerossl.com/v2/DV90"}
caddyaws2023  | {"level":"info","ts":1675008236.4299083,"logger":"tls.issuance.acme.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme.zerossl.com/v2/DV90/order/A-Ipu8zXJvrtt8Tit59eNA"}
caddyaws2023  | {"level":"info","ts":1675008282.009358,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":1,"first_url":"https://acme.zerossl.com/v2/DV90/cert/ov2FO9h15NjWjCThsQBhkA"}
caddyaws2023  | {"level":"info","ts":1675008282.009628,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"testicule.example.com"}
caddyaws2023  | {"level":"info","ts":1675008282.0096378,"logger":"tls.obtain","msg":"releasing lock","identifier":"testicule.example.com"}

Example of caddyfile

{$DOMAIN}:443 {
  log {
    level INFO
    output file {$LOG_FILE} {
      roll_size 10MB
      roll_keep 10
    }
  }

  tls {
    dns route53 {
      max_retries 10
      aws_profile {$aws_profile}
      access_key_id {$access_key_id}
      secret_access_key {$secret_access_key}

    }
  }
  reverse_proxy code-server:8443
}

May be am I missing a parameter for the new version?
Also, I got some servers working with Letsencrypt certs with this exact config.. This time, it pumped a Zero ssl, I have no clue why this happens.

Thanks for any help

Downloads fail if this plugin is requested (Linux arm64)

Sorry, this seems like the wrong venue, I don't know where to report this - downloads (including on the website and by the experimental caddy add-package) are failing if I request this package.

Works:

#  curl --verbose --output /usr/local/bin/caddy 'https://caddyserver.com/api/download?os=linux&arch=arm64'

Doesn't:

# curl --verbose --output /usr/local/bin/caddy 'https://caddyserver.com/api/download?os=linux&arch=arm64&p=github.com%2Fcaddy-dns%2Froute53'

Other packages (such as mholt/caddy-l4) seem fine, as do other architectures.

Error during install module

This is steps for reproduce.
1 docker run -it caddy:2.4.6-builder-alpine ash
2 xcaddy build --with github.com/caddy-dns/route53
result

go get: added google.golang.org/protobuf v1.27.1
2023/03/14 07:17:14 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v github.com/caddy-dns/route53
github.com/caddy-dns/route53 imports
	github.com/caddyserver/caddy/v2 imports
	net/netip: package net/netip is not in GOROOT (/usr/local/go/src/net/netip)

Unable to pass delegated DNS challenge when using caddy dns_challenge_override_domain

I am onboarding clients with their custom domains, with the aim of creating a certificate for manage.clientsite.com and a wildcard certificate for *.manage.clientsite.com. To do this the client sets a CNAME record to delegate the DNS challenge as follows:
_acme-challenge.manage.clientsite.com > _acme-challenge.appsite.com (also tried _acme-challenge.manage.appsite.com)

This is the caddy config:

`{
acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

*.manage.clientsite.com, manage.clientsite.com {
reverse_proxy 127.0.0.1:8090

tls {
	dns route53 {
		aws_profile "my_profile"
		max_retries 1
	}
	dns_challenge_override_domain appsite.com
}

}
`

The result is a clean up error, and an error suggesting the cname record already exists (it does not exist before or after this process).

2022/08/08 10:45:13.352 ERROR tls.issuance.acme.acme_client cleaning up solver {"identifier": "manage.clientsite.com", "challenge_type": "dns-01", "error": "no memory of presenting a DNS record for manage.clientsite.com (probably OK if presenting failed)"} 2022/08/08 10:45:13.505 ERROR tls.obtain could not get certificate from issuer {"identifier": "manage.clientsite.com", "issuer": "acme-staging-v02.api.letsencrypt.org-directory", "error": "[manage.clientsite.com] solving challenges: presenting for challenge: adding temporary record for zone appsite.com.: InvalidChangeBatch: operation error Route 53: ChangeResourceRecordSets, https response error StatusCode: 400, RequestID: 582cde5f-a271-487f-92a0-123, InvalidChangeBatch: [Tried to create resource record set [name='appsite.com.', type='TXT'] but it already exists] (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/123/123) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}

If I set the dns_challenge_override_domain to _acme-challenge.appsite.com (I've been advised it shouldn't need to be this), then it works as far as the certificates do get generated, but then it fails when it tries to clean up the acme challenge dns record.

2022/08/08 09:41:43.159 ERROR tls.issuance.acme.acme_client cleaning up solver {"identifier": "*.manage.clientsite.com", "challenge_type": "dns-01"}

I haven't found any combination of configuration settings that will allow the dns challenge to be delegated to another domain, and for it to create and delete the dns challenge record.

UPDATE: I have also tested this with a simpler config, just using the manage.clientsite.com and not trying to create the wildcard certificate as well, the result is the same.

This module does not build

First saw the issue in xcaddy.

However, even if I try to just "get" the module I get this error:

go get github.com/caddy-dns/route53
go: downloading github.com/caddy-dns/route53 v1.1.0
go: github.com/caddy-dns/route53 upgrade => v1.1.0
go: downloading github.com/libdns/route53 v1.0.1
# github.com/caddy-dns/route53
../../../../../../pkg/mod/github.com/caddy-dns/[email protected]/route53.go:32:12: p.Provider.AWSProfile undefined (type *"github.com/libdns/route53".Provider has no field or method AWSProfile)
../../../../../../pkg/mod/github.com/caddy-dns/[email protected]/route53.go:60:16: p.Provider.AWSProfile undefined (type *"github.com/libdns/route53".Provider has no field or method AWSProfile)

wildcard SSL certificate not working aws dynamic subdomain

here is my caddy file on ubuntu OS
Im trying to get subdomain to work with my domain but subdomain doesn't generate ssl certificate
all my certificates are hosted on s3 so i have both s3 storage plugin and dns route 53 plugin


*.mysite, mysite {
tls {
		 dns route53 {
    max_retries 10 
    aws_profile "my profile" 
    access_key_id "my-profile-access-key" 
    secret_access_key "my-profile-secret-key" 
    token "my-profile-secret-key" 
    region "eu-west-3" 
  }
	}
        root * /var/www/mysite/public
        encode zstd gzip
        file_server
         php_fastcgi unix//var/run/php/php8.2-fpm.sock

}

here is my caddy log


Jan 21 22:05:17 ip-172-31-39-194 caddy[249127]: {"level":"info","ts":1674338717.9979832,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.testlave.live"}
Jan 21 22:05:18 ip-172-31-39-194 caddy[249127]: {"level":"info","ts":1674338718.422322,"logger":"http.acme_client","msg":"trying to solve challenge","identifier":"*.testlave.live","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
Jan 21 22:05:18 ip-172-31-39-194 caddy[249127]: {"level":"error","ts":1674338718.7669091,"logger":"http.acme_client","msg":"cleaning up solver","identifier":"*.testlave.live","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.testlave.live\" (usually OK if presenting also failed)"}
Jan 21 22:05:18 ip-172-31-39-194 caddy[249127]: {"level":"error","ts":1674338718.9066675,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.testlave.live","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.testlave.live] solving challenges: presenting for challenge: adding temporary record for zone \"testlave.live.\": operation error Route 53: ListHostedZonesByName, https response error StatusCode: 403, RequestID: 6563e61e-134a-4fd2-bf70-7607d883a16e, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/84131713/6694827993) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
Jan 21 22:05:20 ip-172-31-39-194 caddy[249127]: {"level":"info","ts":1674338720.8710263,"logger":"http.acme_client","msg":"trying to solve challenge","identifier":"*.testlave.live","challenge_type":"dns-01","ca":"https://acme.zerossl.com/v2/DV90"}
Jan 21 22:05:21 ip-172-31-39-194 caddy[249127]: {"level":"error","ts":1674338721.2110147,"logger":"http.acme_client","msg":"cleaning up solver","identifier":"*.testlave.live","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.testlave.live\" (usually OK if presenting also failed)"}
Jan 21 22:05:21 ip-172-31-39-194 caddy[249127]: {"level":"error","ts":1674338721.700836,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.testlave.live","issuer":"acme.zerossl.com-v2-DV90","error":"[*.testlave.live] solving challenges: presenting for challenge: adding temporary record for zone \"testlave.live.\": operation error Route 53: ListHostedZonesByName, https response error StatusCode: 403, RequestID: 46ad2d23-adcd-40f0-830e-8da7edda790f, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. (order=https://acme.zerossl.com/v2/DV90/order/cM01XC8kmxAyX93orxXaxQ) (ca=https://acme.zerossl.com/v2/DV90)"}
Jan 21 22:05:21 ip-172-31-39-194 caddy[249127]: {"level":"error","ts":1674338721.7011356,"logger":"tls.obtain","msg":"will retry","error":"[*.testlave.live] Obtain: [*.testlave.live] solving challenges: presenting for challenge: adding temporary record for zone \"testlave.live.\": operation error Route 53: ListHostedZonesByName, https response error StatusCode: 403, RequestID: 46ad2d23-adcd-40f0-830e-8da7edda790f, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. (order=https://acme.zerossl.com/v2/DV90/order/cM01XC8kmxAyX93orxXaxQ) (ca=https://acme.zerossl.com/v2/DV90)","attempt":4,"retrying_in":300,"elapsed":319.633461226,"max_duration":2592000}

end of log

Please help me . Im assuming the error has to do with token Id value cause i tried using both access & secret key but to no availโ€™
when i create my iam user,AWS gives me only access key & secret key so dont know what to put at token

If my assumptions are wrong, please correct me in the right direction

Can't find AWS profile

Hello,
I am trying to set up caddy to use route53 and xcaddy is spitting out an error about not finding the ~/.aws/credentials, even though the aws cli finds them just fine.

Below is the error.

2020/12/08 16:33:12 [INFO] Writing main module: /tmp/buildenv_2020-12-08-1633.970086107/main.go
2020/12/08 16:33:12 [INFO] Initializing Go module
2020/12/08 16:33:12 [INFO] exec (timeout=10s): /usr/local/go/bin/go mod init caddy
go: creating new go.mod: module caddy
2020/12/08 16:33:12 [INFO] Replace github.com/caddy-dns/route53 => /home/<user>/.aws/route53
2020/12/08 16:33:12 [INFO] exec (timeout=10s): /usr/local/go/bin/go mod edit -replace github.com/caddy-dns/route53=/home/<user>/.aws/route53
2020/12/08 16:33:12 [INFO] Pinning versions
2020/12/08 16:33:12 [INFO] exec (timeout=0s): /usr/local/go/bin/go get -d -v github.com/caddyserver/caddy/v2
go: github.com/caddyserver/caddy/v2 upgrade => v2.2.2
2020/12/08 16:33:13 [INFO] Build environment ready
2020/12/08 16:33:13 [INFO] Building Caddy
2020/12/08 16:33:13 [INFO] exec (timeout=0s): /usr/local/go/bin/go build -o /home/<user>/.aws/route53/caddy -ldflags -w -s -trimpath
go: found github.com/caddy-dns/route53 in github.com/caddy-dns/route53 v0.0.0-00010101000000-000000000000
# github.com/caddy-dns/route53
/home/ascii17/.aws/route53/route53.go:58:16: p.Provider.AWSProfile undefined (type *"github.com/libdns/route53".Provider has no field or method AWSProfile)
2020/12/08 16:33:14 [INFO] Cleaning up temporary folder: /tmp/buildenv_2020-12-08-1633.970086107
2020/12/08 16:33:14 [ERROR] exit status 2

Here is the process that I used to install xcaddy and tried to install dns.providers.route53
go get -u github.com/caddyserver/xcaddy/cmd/xcaddy

xcaddy build v2.3.0-beta.1 --with github.com/caddy-dns/route53

At this point dns.providers.route53 does not show up in caddy list-modules

admin.api.load
admin.api.metrics
caddy.adapters.caddyfile
caddy.listeners.tls
caddy.logging.encoders.console
caddy.logging.encoders.filter
caddy.logging.encoders.filter.delete
caddy.logging.encoders.filter.ip_mask
caddy.logging.encoders.json
caddy.logging.encoders.logfmt
caddy.logging.encoders.single_field
caddy.logging.writers.discard
caddy.logging.writers.file
caddy.logging.writers.net
caddy.logging.writers.stderr
caddy.logging.writers.stdout
caddy.storage.file_system
http
http.authentication.hashes.bcrypt
http.authentication.hashes.scrypt
http.authentication.providers.http_basic
http.encoders.gzip
http.encoders.zstd
http.handlers.acme_server
http.handlers.authentication
http.handlers.encode
http.handlers.error
http.handlers.file_server
http.handlers.headers
http.handlers.map
http.handlers.metrics
http.handlers.push
http.handlers.request_body
http.handlers.reverse_proxy
http.handlers.rewrite
http.handlers.static_response
http.handlers.subroute
http.handlers.templates
http.handlers.vars
http.matchers.expression
http.matchers.file
http.matchers.header
http.matchers.header_regexp
http.matchers.host
http.matchers.method
http.matchers.not
http.matchers.path
http.matchers.path_regexp
http.matchers.protocol
http.matchers.query
http.matchers.remote_ip
http.matchers.vars
http.matchers.vars_regexp
http.reverse_proxy.selection_policies.first
http.reverse_proxy.selection_policies.header
http.reverse_proxy.selection_policies.ip_hash
http.reverse_proxy.selection_policies.least_conn
http.reverse_proxy.selection_policies.random
http.reverse_proxy.selection_policies.random_choose
http.reverse_proxy.selection_policies.round_robin
http.reverse_proxy.selection_policies.uri_hash
http.reverse_proxy.transport.fastcgi
http.reverse_proxy.transport.http
pki
tls
tls.certificates.automate
tls.certificates.load_files
tls.certificates.load_folders
tls.certificates.load_pem
tls.handshake_match.sni
tls.issuance.acme
tls.issuance.internal
tls.issuance.zerossl
tls.stek.distributed
tls.stek.standard

So I run xcaddy list-modules to get that original error message.

My OS is as follows:

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04

My Go version is:

go version go1.15.6 linux/amd64

And Caddy is:

v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

Use AWS Credentials from environment variables

Is it possible to use AWS credentials from the environment (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) first if they exist?

I would be happy to make a PR if there are no issues with the idea.

This module needs to use Provision()

The libdns/route53 package has a NewSession() method:

route53/route53.go

Lines 24 to 30 in 8c20bfe

p := &Provider{new(route53.Provider)}
// Initialize the AWS client session
err := p.NewSession()
if err != nil {
return nil
}
return p

The New() function should not perform any provisioning: https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#ModuleInfo

The Provisioner interface should be implemented instead.

(Labelling as a bug since it violates the doc.)

dependency of caddy v2.4.5 requires golang v1.16

this module was updated to use caddy v2.4.5 as a dependency. as of caddy v2.4.4 (i think?), support for golang < 1.16 was dropped. this module should probably at the very least have its min. go version set to 1.16 to match.

github.com/caddyserver/caddy/v2 v2.4.5

Missing License

This project does not have a license. It would be great if you could add a license to the project, presumably an MIT license like the one in the template repository.

Provider has no field or method NewSession

I created a fork of libdns/route53 in order to test some of the recent bug fixes (libdns/route53#7, libdns/route53#12) and I ran across this error:

/go/pkg/mod/github.com/eth-limo/[email protected]/route53.go:35:10: p.NewSession undefined (type *Provider has no field or method NewSession)

For testing purposes I pinned libdns/route53 to v1.2.1-0.20220707195619-cc1414081972 which includes an upgrade to the AWS SDK and a few other fixes.

I'm building Caddy with the following command:

go get github.com/caddyserver/xcaddy/cmd/xcaddy && \
    xcaddy build v2.5.1 \
      --with github.com/eth-limo/[email protected]

I'm assuming this will be an issue once this project upgrades libdns/route53 to v1.2.1.

Thanks!

When a split-view DNS is used records can be created in the private zone

We have set a split-vew DNS.

Hosted zones have zone IDs like below - I provide them becaIse I think that it's important.

public: Z09013XXXXXXXXX3VLIRX
private: Z04371XXXXXXXXXOAC4E

The DNS challenge fails because plugin try to create records in the private zone (I assume that the private zone zone is returned by AWS as the first - due to alphabethical order).

I found workaround for now. To use a separate subdomain and use dns_challenge_override_domain option but it's required additional work.

Can you implement an optional parameter zoneID?

IMHO, the libdns\route53 has that parameter implemented.

New release?

Thanks for accepting my PR. However, can you do a new release?

The v1.1.0 release is broken. Master is now fixed but there is no tag for it. So this module will still not work in xcaddy or really even in go...

All that is needed is for someone to tag what is currently on master with a new version number.

ttl for route53 should be sent as seconds

๐Ÿ‘‹

I'm using caddy to request certificates through route53 provider

{
  "module": "acme",
  "challenges": {
    "dns": {
      "provider": {
        "name": "route53"
      },
      "ttl": "1h"
    }
  }
}

unfortunately it seems like the ttl of 1 hour is translated to 3600000000000 while the dns errors out saying that max is 2147483647

{
  "level": "error",
  "ts": 1632395039.5339599,
  "logger": "tls.obtain",
  "msg": "will retry",
  "error": "[siasky.dev] Obtain: [siasky.dev] solving challenges: presenting for challenge: adding temporary record for zone siasky.dev.: InvalidInput: InvalidInput: 1 validation error detected: Value '3600000000000' at 'changeBatch.changes.1.member.resourceRecordSet.tTL' failed to satisfy constraint: Member must have value less than or equal to 2147483647\n\tstatus code: 400, request id: 21b98755-2e7b-47f8-abad-d8eb24207a81 (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/27549458/598268258) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)",
  "attempt": 2,
  "retrying_in": 120,
  "elapsed": 63.129179538,
  "max_duration": 2592000
}

seems to me there should be some conversion going on for route53 so that the number is sent as seconds so 3600 instead of 3600000000000

TTL (seconds)
The amount of time, in seconds, that you want DNS recursive resolvers to cache information about this record. If you specify a longer value (for example, 172800 seconds, or two days), you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service. For more information, see How Amazon Route 53 routes traffic for your domain.

https://aws.amazon.com/route53/faqs/

AWS Credentials Multi-Profile Support

Hi all, I'm currently running Caddy from a docker image (latest), and alpine builder (latest)..

I was able to get Automatic HTTPS working (thru DNS Validation) by building caddy with route53 dns module and adding the default "Profile" in the AWS Credentials configuration in the ~/.aws/credentials path as in:

[default]
aws_access_key_id = <YOUR_DEFAULT_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_DEFAULT_SECRET_ACCESS_KEY>

Everything was working fine until the time I needed to add another "Profile" from another AWS account as in:

[development]
aws_access_key_id = <YOUR_DEFAULT_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_DEFAULT_SECRET_ACCESS_KEY>

[production]
aws_access_key_id = <YOUR_DEFAULT_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_DEFAULT_SECRET_ACCESS_KEY>

And now I don't know how to specify in the virtual-host section of the caddyfile about which aws profile/account it should use to connect for route53 dns validation...


Here's my current caddyfile:

dev.example.com:443 {
  bind {$ADDRESS}
  header X-Robots-Tag noindex
  reverse_proxy /* dev:80 {
      header_up Host "dev.example.com"
  }
  tls {
      dns route53 # from the development aws account
  }
}
prod.example.com:443 {
  bind {$ADDRESS}
  header X-Robots-Tag noindex
  reverse_proxy /* dev:80 {
      header_up Host "prod.example.com"
  }
  tls {
      dns route53 # from the production aws account
  }
}

In contrast to the cloudflare DNS module, I can specify the API key in the caddyfile itself so no worries on how many cloudflare accounts I use it with as in:

dev.example.com:443 {
  bind {$ADDRESS}
  header X-Robots-Tag noindex
  reverse_proxy /* dev:80 {
      header_up Host "dev.example.com"
  }
  tls {
      dns cloudflare "redacted-key"
  }
}

Is there somehow a way to specify the AWS credentials profile that I want to use for DNS validation?

certificate issuing fails because records already exists

hello,
we are trying to make this module work on caddy 2.3.4, and we hit an issue with the DNS entries creation.

starting clean (no dns records, no caddy data volume) during startup caddy creates (and deletes, and creates, etc.) records on route 53 until it fails saying that the records (that the plugin just created) already exists and cannot proceed.

we tried this procedure starting from a clean slate on 4 machines (not at the same time) and it worked on 2 but failed on the other two.

we are trying to make this setup useable by more than one machine, we had this setup with caddy-gen (v1) and everything worked; here we are hitting the fact that the plugin says the records already exists and stops.

I tried looking at the source of this and libdns/route53 and I see there are methods to update the records instead of creating them, but I'm unsure where/how they are called.

any clue what might be wrong?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.