Adding wrong domain name to AWS

[romuloalves]

Description

I'm running the command up stack plan to add the domain supremasuprimentos.com.br and the Up is adding .com.br.

Steps to Reproduce

I have configured the stages.production like this:

"stages": {
    "production": {
      "domain": "supremasuprimentos.com.br"
    }
  }

After running up stack plan the output (with the flag --verbose) is the code below:

     $ up stack plan --verbose
     41ms    DEBU up version 0.2.5
     0s      DEBU 1 regions from config
     0s      DEBU track "Plan Stack" map[arch:amd64 version:0.2.5 os:darwin]
     1.993s  DEBU event stack.plan map[region:us-east-2]
     459ms   DEBU looking up cert for supremasuprimentos.com.br
     4.262s  DEBU event platform.certs.create map[domains:[com.br]]
     923ms   DEBU event platform.certs.create.complete map[domains:[com.br] duration:4.261706919s]
     1.736s  DEBU finding stage dns zones for production com.br (supremasuprimentos.com.br)
     1.135s  DEBU deleting changeset
     1.121s  DEBU creating changeset
     270ms   DEBU describing changeset
     751ms   DEBU waiting for completion
     316ms   DEBU describing changeset
     755ms   DEBU waiting for completion

[tj]

oops that's my bad, naive implementation of sub-domain checks, thanks for the report!

[jonotron]

I experienced the same issue yesterday, tried using dev.api.MYDOMAIN.com, ACM requested a certificate for MYDOMAIN.com (with additional name *.MYDOMAIN.com). It also sent me 12 emails (go figure)

It configured API gateway correctly.

[tj]

@jonotron haha yea AWS goes a little nuts trying a bunch of domains, hope they change how verification is done at some point, it's a little awkward.

It's written to request only one ACM cert for say example.com and *.example.com, but I overlooked the second-level domain case. I'll have to tighten that logic up.

[jonotron]

@tj I like how easy ACM is, but man... email verification as the only option? I really wish for some Let's Encrypt style checks... especially when the domain is in Route53 in the first place.

If I head to dev.api.example.com I get a net::ERR_CERT_COMMON_NAME_INVALID and the certificate has a common name of just example.com. Not sure if that's related?

[mitchellhuang]

@jonotron *.*.example.com !== *.example.com. I believe you need to explicitly add dev.api.example.com to your certificate to access another subdomain level.

[tj]

I can't think of any magical way to differentiate between foo.example.com and example.co.uk etc for now, aside from whitelisting all of the official second-level domains. If anyone has an idea there let me know!

For now I think it might be best to avoid the wildcard stuff I have in there, but it comes at the cost of annoying confirmations for any sub-domains you want to use certs for, but at least we can avoid these cases, oversight on my part.