Single cert, multi domain, split visibility?


Trying to figure out how to best pull off a strange arrangement, due to dumb EC2 instance requirements.

Due to circumstances beyond my control, I need to set up a AWS EC2 instance within a VPC with a public IP and a web interface that is also behind an AWS ALB load balancer. Naturally the AWS ALB can make SSL certs for itself via DNS validation (which appears to be able to use non-renewing/changing challenge CNAME entries). I can manually change DNS by hand, but only directly at an on-premises DNS server which replicates to an external third party DNS secondary server via restricted zone transfer, and is otherwise really locked down internally and externally.

For policy reasons, I need to make the EC2 instance web interface admin page viewable to a restricted set of IP’s, but the instance itself has no mechanism to filter access internally. Right now the EC2 instance has an inbound security group limiting access by IP on its public IP, but the ALB has a security group that is open to everybody (by necessity of being a global public HTTP/HTTPS interface).

The basic idea is management users want an SSL entrance to the web admin page via a direct DNS mapped name to the EC2 public IP, secure the traffic between the ALB and EC2 instance with SSL, and do some lame path filtering within the ALB to “protect” the web admin page.

certbot is available in the EC2 instance

This presents the problem that the EC2 instance can use a webroot authentication for domain names that point to the ALB and get passed through (can configure a HTTP bypass based on a DNS/path filter like hostname/.well-known/* ), but any DNS name directly mapped to the EC2 instance will fail webroot validation since it’s unreachable by the LE validation servers (whose IP’s are not publicly known on purpose, so can’t be preauthorized in the AWS security group inbound rules). With DNS changes being a highly manual affair that has to be done internally, I can’t automate replacing DNS challenges from the EC2 instance. TLS and standalone HTTP challenges for the direct DNS name won’t work since the IP is effectively unreachable.

Is is basically not worth the effort to get a multidomain certificate where only some of the names are effectively visible to LE validation servers when no DNS API is available?

I really wish the DNS was running on Route53, but that isn’t going to happen. I suspect I probably can’t do a split visibility multidomain cert, and will likely have to do something questionable like hand setting up AWS WAF rules on the ALB to do the IP filtering there, and force filter the webadmin access through the ALB.



In your case, certbot (or even let’s Encrypt) may not be a good idea to use.
AWS ACM provides a way to request & issue & renew certificates automatically using cname method. Once you added the cname to your DNS, you’ll not need further change when you’re trying to renew the certificate.

It’s not worthy to spend lots of time trying to figure out how to use let’s encrypt to setup mutlidomain certificate. You could archive the same using DNS (cname validation) with AWS ACM.

Hope it helps.

Thank you


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.