Closed sapid closed 8 months ago
If you are using quotes around the values of your variables, remove them.
I need to add to my to-do list to deal with if people do that since it’s a pretty common format.
If that’s not it, let me know.
:facepalm: Yep, that was it. I didn't look closely enough at config.example.yaml
to notice that environment variables don't share the same format as all other arguments.
I'll also make some new screenshots for dns01 acme.sh and dns01 go-acme le-go and make a PR.
I submitted https://github.com/gregtwallace/legocerthub.com-docusaurus/pull/2 for this issue.
The new version is building and the this should work now with or without quotes. Thanks for raising this. The update should avoid what might be a common confusion since the param format often includes quotes.
My current goal is to create a wildcard SSL cert on a network behind a NAT. As such, I'm trying to use the DNS-01 challenge method using an API for Route 53. I'm using a root-less installation, and I have
legocerthub
running on linux (not in Docker) using the provided installation script (scripts/install.sh
) with the caveat that I did not grantCAP_NET_BIND_SERVICE
tolegocerthub
since I don't plan on exposing a port through the NAT for the http challenge (in spite of the headache it would save me).I've successfully used both
lego
andacme.sh
to accomplish cert issuance with the Let's Encrypt staging ACME server with my credentials for Route 53, but I get errors inlegocerthub
when I use either Providersdns01acmesh
ordns01goacme
. All of these experiments below are performed from the same machine.dns01acmesh
In the case of
dns01acmesh
, it looks to me like the root cause is that something is preventingacme.sh
from reading from or writing to its config file. I get this error whenacme.sh
's path is specific as/opt/legocerthub/.acme.sh
and as/opt/legocerthub/scripts/acme.sh
. (The write error could be a red herring if not saving the config is the intended outcome, but as I mentioned above, the same tokens specified here work from the cli with both tools, and they look correct indata/app/config.yaml
, so the alternative appears perhaps to be passing the credentials to acme.sh incorrectly.)The valid CLI invocation looks like:
Config for
dns01acmesh
:dns_hook
is configured todns_aws
.AWS_ACCESS_KEY_ID="MY_VALID_KEY"
AWS_SECRET_ACCESS_KEY="MY_VALID_SECRET_KEY"
AWS_DNS_SLOWRATE="1"
LE_CONFIG_HOME=/opt/legocerthub/.acme.sh/
Relevant log output
After successfully fetching the challenge, here's what the logs look like. I wish the
debug
log level showed howacme.sh
is being invoked.dns01goacme
cli execution
Config for
dns01goacme
code
is set toroute53
AWS_SHARED_CREDENTIALS_FILE="/opt/legocerthub/.aws/credentials"
AWS_REGION="us-west-1"
AWS_HOSTED_ZONE_ID="MY_ZONE_ID"
Relevant log output
This one's a bit more puzzling to me, though my (perhaps naive) guess is that it's trying to query EC2 IMDS at 169.254.169.254 instead of directly using the provided credentials with
route53.amazonaws.com
. (Trying to verify the credentials with IMDS this way will fail in my idiosyncratic case - the IMDS for my Route 53 AWS account and my network AWS account are disjoint.)Explicitly declared credentials for
dns01goacme
Modifying the configuration slightly renders a slightly different error message, but I think it supports my IMDS theory. If, instead of referencing the credential file, I specify
AWS_ACCESS_KEY_ID="MY_VALID_KEY"
andAWS_SECRET_ACCESS_KEY="MY_VALID_SECRET_KEY"
, I get the following log output instead. The error suggests I don't have valid credentials, but invokingaws route53 list-resource-record-sets --hosted-zone-id
from the terminal verifies that I do have that IAM permission for these credentials.