0

I would like to be able to replicate a site built in an existing, working EC2 Linux 2 AMI image in a manner that does not require re-provisioning of https certificates when spinning up a saved AMI on a different address. The web server is stock httpd (Apache2). It has a certbot certificate for use on data1.mydomain1.com. I want TLS to work when I spin up the saved AMI on data2.mydomain.com (or data3... data4... etc., or stuff.anotherdomain.org) - without having to re-run certbot on every new instance. Is there a clean way to do this in advance? Note that because these are separate running instances, this is not a wildcard or alias situation where the names resolve to the same IP address (or are routed on the same server).

I tried

sudo certbot --expand data1.mydomain.com,data2.mydomain.com

However, data2.mydomain.com came up "not secure" (http://), although data1.mydomain.com continued to work (https://).

Improve this question
1
  • Welcome to ServerFault. I don't think there is a clean way to do this. However, wildcard cert might fit your scenario. However, initial deployment and then updating it regularly will introduce additional issues that are not easier than provisioning individual cert in each server.
    – Pothi Kalimuthu
    Jan 14 at 6:24

1 Answer 1

Reset to default
0

You could go with a wildcard certificate, but I believe that requires DNS validation. Which does work with a few different DNS providers, including Route53. So request the certificate for *.mydomain.com.

Alternatively you could use a load balancer and ACM to issue certificates, but you would need to do a little scripting around creating the routing rules and certificates (or use a wildcard cert). Again DNS validation would be needed.

Improve this answer
9
  • Doesn't the DNS wildcard *.mydomain.com just resolve any arbitrary subdomain of mydomain.com to a single specified IP? (It seems to work that way on Namecheap). What I want to do is deploy a replica instance of my working server (with different application data) on a different IP. So I could have one application running on a first instance on data1.mydomain.com, and a second like application running on a different instance, on data2.mydomain.com.
    – Ron Abramson
    Jan 5 at 21:55
  • Maybe it will work anyway, will try a wildcard certificate. Guess the real question may be how the DNS provider deals with the *, if other specific subdomains are already defined. Hopefully the specific A records will take precedence in terms of the IP directed to, and the wildcard certificate will nevertheless work. Giving it a try ...
    – Ron Abramson
    Jan 6 at 0:36
  • @RonAbramson: DNS wildcards and TLS certificate wildcards are different things. To get a wildcard (TLS) cert from LE you must pass the DNS-01 challenge on the non-wild parent domainname: community.letsencrypt.org/t/… ; no wildcard DNS request is attempted.
    – dave_thompson_085
    Jan 6 at 3:46
  • Thanks, yes I see that, TLS wildcard refers to a certificate that will work with wildcard subdomain and is tested against proven ownership of the parent domain. So wildcard certificate seems to be the way to go here.
    – Ron Abramson
    Jan 6 at 19:09
  • Also note how to set the TXT records for a wildcard certificate. It looks like certbot tests control over the domain by making you install some TXT records that it specifies during setup, and verifying you were able to do it. TXT records are key-value pairs. The name part of this pair that certbot gives you is _acme-challenge.yourdomain.com. The hint here is that you only enter the "_acme-challenge" part of the name, not the ".yourdomain.com" (which is implicit). Then test it with a dig tool, looking for a TXT record at _acme-challenge.yourdomain.com. It can take a good while to show up.
    – Ron Abramson
    Jan 7 at 18:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .