copilot-cli: copilot app init --domain followed by copilot init fails due to HTTPSCert

I ran the following commands:

$ copilot app init --domain aws.spellbot.io
$ copilot init

Use existing application: No
Workload type: Backend Service
Service name: spellbot
Dockerfile: ./Dockerfile.bot
Deploy: Yes

And encountered the following errors. Everything else seemed to work except HTTPSCert.

The following resource(s) failed to create: [HTTPSCert]

- A Route 53 Hosted Zone for the environment's subdomain:

    The specified hosted zone contains non-required resource record sets
    and so cannot be deleted. (Service: Route53, Status Code: 400, Request
    ID: a28557c2-1a40-458a-a49e-27b84bb702c6, Extended Request ID: null)
    The specified hosted zone contains non-required resource record sets
    and so cannot be deleted. (Service: Route53, Status Code: 400, Request
    ID: 586c74d4-e434-42ce-9a67-e13c24fd4a1a, Extended Request ID: null)

- Request and validate an ACM certificate for your domain:

    Received response status [FAILED] from custom resource. Message return
    ed: Resource is not in the state certificateValidated (Log: /aws/lambd
    a/spellbot-test-CertificateValidationFunction-RYnN39hsF5fa/2022/12/14/
    [$LATEST]1d2aba50501a4172a4c4c1f0518ca852) (RequestId: f03478d7-1e1b-4
    164-a6ab-4656db5ab632)
    Received response status [FAILED] from custom resource. Message return
    ed: Cannot read properties of undefined (reading 'Name') (Log: /aws/la
    mbda/spellbot-test-CertificateValidationFunction-RYnN39hsF5fa/2022/12/
    14/[$LATEST]1d2aba50501a4172a4c4c1f0518ca852) (RequestId: 4f475642-c54
    4-4b6f-b466-98691b1a0fc0)

After hanging for over 20 minutes the process started emitting a line like the following 10 times a second until I killed it.

- Creating the infrastructure for the spellbot-test environment.                     [update rollback complete cleanup in progress]  [1159.9s]

Note that I have 3 hosted zones, and one of them is my aws.spellbot.io HZ that I created manually before running the copilot commands. I then set up NS records for the Name servers created by that HZ in my DNS management tool of my personal website.

Should I have not done that? Is it confused because I manually set up the HZ myself?

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 31 (11 by maintainers)

Commits related to this issue

chore: lookup NS records of domain to validate route53 as DNS service (#4281) Previously, we would log a warning when a user bought a domain outside of Route53 but correctly migrated to using Route53... — committed to aws/copilot-cli by efekarakus 2 years ago

Most upvoted comments

Hi @lexicalunit!

Hopefully I can help. Focusing on getting the Copilot ACM automation. It’s likely that your CAA record is causing the issues. If you have not modified it, that’s the root cause.

Perform the following:

(AWS) Create a public hosted zone for aws.spellbot.io.
(Parent zone registrar) Take the 4 name server hosts and create NS records in the parent zone spellbot.io

Ref A

Additionally, you will need to have a proper CA authorization record (CAA). They are hierarchical. CAs will search the most specific subdomain for authorization first (aws.spellbot.io, then spellbot.io) This shows that you have only authorized letsencrypt.org for your entire domain hierarchy. To ensure AWS ACM can issue certificates, you can do one of the following:

Add to the current CAA record in your parent domain. It looks like you could click Add Parameter in the DNS-CAA UI.
Create a new CAA record in your aws.spellbot.io subdomain. This allows you to restrict ACM to only issue certificates for the aws.spellbot.io subdomain.

Refs A B

You will need to add this data into either CAA record:

0 issue "amazon.com"
0 issue "amazontrust.com"
0 issue "awstrust.com"
0 issue "amazonaws.com"

If you do option # 2, it should look like this:

After that you should be able to begin to use Copilot.

# The following will create a new Route53 hosted zone of ${AppName}.${DomainName}
copilot app init --domain aws.spellbot.io

# If you elect to deploy as part of the `copilot svc init`,
# a 'test' environment will be created, and
# a new Route53 hosted zone of test.${AppName}.${DomainName} will be created.
#
# Next an ACM certificate *request* will be created for
# test.${AppName}.${DomainName} and *.test.${AppName}.${DomainName}.
#
# The ACM DNS validation records (CNAMEs) will be automatically added to the test.${AppName}.${DomainName}
# Route53 hosted zone.
copilot svc init

The AWS ACM console will show you the status of the certificate issuance.

matthewhembree on Jan 10, 2023

I’d done everything except for step 4 there, maybe that was the issue?

lexicalunit on Dec 15, 2022

@efekarakus yeah definitely got that message. What I learned, and I guess I should have known by now, is that even though you pass a root hosted zone, copilot will not when using an alias create more than a single hosted zone off of that. If your root is example.com, you can’t set an alias like api.appName.example.com as appName.example.com doesn’t exist or may not be owned by copilot. We temporarily renamed to appName-api.example.com to get around for the moment.

h5aaimtron on Dec 15, 2022

There is also another alternative for getting https://aws.spellbot.io to work with Copilot: https://aws.github.io/copilot-cli/docs/developing/domain/#use-domain-in-your-existing-validated-certificates

So you can keep your existing, and navigate to AWS Certificate Manager to create a certificate for aws.spellbot.io. Then in your environment manifest, you can add the certificate to the load balancer: https://aws.github.io/copilot-cli/docs/manifest/environment/#http-public-certificates Then you can point to the aws.spellbot.io domain to the load balancer and it should work! However, the tradeoff is that it’s a lot more steps than the --domain flag

This is ultimately what I did 👍🏻

lexicalunit on Dec 15, 2022

Which region are you deploying in? ACM certificate validation can sometimes take a long time, and we have a timeout for the Lambda function that creates the certificate for 15 mins 💭 .

I’ve been trying us-east-1. It does seem like it takes about 15 minutes for the error to occur.

lexicalunit on Dec 15, 2022

Which region are you deploying in? ACM certificate validation can sometimes take a long time, and we have a timeout for the Lambda function that creates the certificate for 15 mins 💭 .

I wonder if we are running into a timeout issue 😢 if so I think the safest bet would be to not use --domain flag, create the ACM certificate separately, and update the environment manifest to use the ACM certificate.

efekarakus on Dec 15, 2022