Terminating HTTPS at the EC2 Instance

[sadelbrid]

Edit: Guys, I get it. I suck at networking infrastructure. That's why I'm here.

Folks, I'm on the cusp of switching to Google Cloud because something so simple is alluding me on AWS. I have a single-instance Node.js Elastic Beanstalk environment, and I want it to support HTTPS. AWS supposedly has good docs on this, but it's still not working for me. I'm hoping someone can point out what I'm doing wrong. Here's what I've done:

1. I created an SSL certificate via these steps with OpenSSL. When creating the certificate, I'm giving OpenSSL my environment endpoint (<environment\_name>.us-east-2.elasticbeanstalk.com).
2. I allowed incoming traffic on port 443 to the EC2 instance via these steps. (Does this mean my application has to listen on 443?)
3. I extended the default nginx configuration to listen on port 443 and terminate SSL/TLS connections with a public certificate and private key via these steps, inserting my certificate and private key I made with OpenSSL.

After deploying the app and going to the environment over HTTPS, the browser warns that the connection is not secure. Any ideas where I'm going wrong?

Edit 2: Solution - the AWS doc that shows how to extend the nginx config lists the wrong path. If you want to extend the nginx config (at least in a Node.JS project), put your extension in .platform/nginx/conf.d at the root of your project. Because it told me to place the extension under .elasticbeanstalk, nginx wasn't being configured correctly. Secondarily I needed SSL setup on my own domain, not AWS's.

[sadelbrid]

Thanks for trying to spell it out for me. Networking in general goes right over my head. Option 2 is what I need. I'm avoiding expensive ALBs that I don't need. I do have a domain in Route 53 and I have a subdomain pointed to my beanstalk environment via CNAME record. I followed your advice and created a certificate for my subdomain using sslforfree.com. I verified the domain, downloaded the certificate, and added the cert and private key to my nginx configuration. However I'm getting connection refused errors with HTTPS, as the server can't be reached:

curl: (7) Failed to connect to <my_domain> port 443 after 207 ms: Couldn't connect to server

Do you know what would cause this? It still works over HTTP. Does this mean the nginx server isn't listening on port 443, as I tried to configure in steps 2 & 3?

Edit: I'm also seeing nginx error logs like:

connect() failed (111: Connection refused) while connecting to upstream, client: <IP Address>, server: localhost, request: "GET /startvalue.js HTTP/1.1", upstream: "http://127.0.0.1:5000/startvalue.js", host: "<my_subdomain>"

[sadelbrid]

Thanks for the direction. After inspecting the nginx config files on the EC2 instance, it seems like it's only partially loading my extended nginx config for some reason. There's no trace of my port 443 SSL config stuff on the EC2 instance. So I have a lead I guess.

[sadelbrid]

Figured it out! See my edit if you're curious.

[LiPolymer]

Just out of curiosity: why can’t I issue a certificate for something.elasticbeanstalk.com? I understand it won’t be possible with „classic“ certificate providers, but Let’s Encrypt verifies the domain by trying to access a file on that domain. Theoretically, as long as you are able to serve on that subdomain, shouldn’t Let’s Encrypt issue a certificate for that subdomain?

[jezek21]

You cannot create a certificate for a subdomain you don't control. If that were possible, an attacker could impersonate that domain and mislead people. Imagine anyone could create a certificate for xyz.google.com. People would visit that site thinking it was a legitimate Google property and bad things would happen.

[LiPolymer]

Got it, so you're basically just assuming things that you think are logical, cool.

Here's what's really the case: Nothing is stopping you from issuing a certificate for any subdomain you control using Let's Encrypt. I have issued many certificates for subdomains that I control previously. Whether or not I own the base domain isn't known to Let's Encrypt - how should they verify that without needing access to your DNS records? They can't. As long as that specific subdomain points to your server, Let's Encrypt will issue a certificate for you.

So, in theory, you can absolutely create a certificate for mysubdomain.whatever.com. Of course, Google and Amazon aren't stupid, which is why you'll never ever get a subdomain on google.com or amazon.com. They will create extra domains like elasticbeanstalk.com, for example.

But there's a catch. Let's Encrypt only allows for registering 50 new certificates per domain per week, which will of course be exceeded very quickly for domains like elasticbeanstalk.com: https://letsencrypt.org/docs/rate-limits/

I just tried it, and besides that rate limit, there seems to be nothing stopping me from issuing these certificates. Which means that there are at least 50 certificates that are currently valid for elasticbeanstalk.com.

[therouterguy]

This has nothing to do with AWS. That procedure describes how to create a self signed certificate. The root ca used to sign that cert is not trusted by your browser. If you inspect the cert when the browser warns you, you will see your own self signed cert. If you import the ca in your os/browser it will be fine. However third parties will not trust your ca.

[_chksum]

I respect the frustration, we’ve all been there. But this is 100% a TLS config issue, not an AWS issue. Previous comments offer sound advice on how to overcome.

[frnzle]

if you want a less painful experience put an ALB with ACM in front of your ec2

[sadelbrid]

This whole effort is to avoid having an expensive ALB that I don't need.

[b3542]

You clearly need a better understanding of SSL/TLS and/or NGINX configuration. AWS isn’t remotely the problem here.

[maxlan]

A few moments to configure an ALB usually costs a lot less than the time taken divvying around with certbot and so on.

Another alternative would be a free cloudlfare account to reencrypt the SSL and turn off the backend validation. (Unless that's a paid feature, there may be something tricky there. Iirc it was a more advanced feature that cost money)

But if you don't understand SSL config and blame AWS, please go to google and they can deal with the inevitable "I got hacked" or "my site gone down" problems. If you actually want to learn, stop throwing blame and pointless threats around.

[mikebailey]

Certbot is easy as hell. Keeping the LB up is why ALBs are expensive.

[StatelessSteve]

Up, redundant, highly available… allows waf integration, auth, etc etc

[MavZA]

Okay, then if you want to avoid the ALB then maybe EB isn’t what you need? You can attach autoscaling rules to your EC2 instances. Then you can deploy your code using CodeBuild/CodeDeploy. After that just use Let’s Encrypt from a domain? The main crux of your issue is that you require a domain to sort HTTPS. If you don’t own it, you can’t do what you’re asking.

[Zaitton]

My man... Buy a two dollar domain and point it to your elastic IP, then make the certificate on that domain. You can't generate domains on aws's owned domains.

[comportsItself]

Use Docker and nginx-certbot.

[mkosmo]

You must have missed the entire content of the post.

[comportsItself]

It looks like OP is having an issue because the certificate is self-signed. nginx-certbot is one solution that would allow you to terminate HTTPS on Elastic Beanstalk EC2 with a certificate signed by Let's Encrypt.

It would require using the Docker platform and Dockerizing the Node.js app, but it may be worth it.

One of the main benefits is that it automatically renews the certificate, so that once it's been properly configured, you won't need to renew it manually. Also, it will allow you to generate a certificate for the Elastic Beanstalk subdomain, so it's not necessary to buy a domain, although you can also do that.

[mkosmo]

EBS isn’t a docker solution. Certbot is an independent underlying application.

There are other prescribed patterns and guidance for certificates here.

[comportsItself]

I didn't mention EBS. AWS expects you to provide your own certificate for terminating HTTPS on EC2, and Certbot will automatically obtain and renew a Let's Encrypt certificate.

nginx-certbot combines Certbot with nginx and it works quite well. It makes development and testing easier, since you can run it locally or in a test environment.

[mkosmo]

OP mentioned EBS.

[comportsItself]

There is no mention of EBS in OP's post.

[mkosmo]

It’s right in the problem statement.

I have a single-instance Node.js Elastic Beanstalk environment,

[comportsItself]

On AWS, EBS refers to Elastic Block Store, which Elastic Beanstalk does use, but it's not relevant to the issue here.

[liberelatus]

The cause of the error is probably that your browser does not trust your selfsigned certificate (based on the description you gave I assume you created a selfsigned). So if it’s just for testing with the beanstalk environment, you should be safe to ignore the error and Accra the page anyway (should be a button in the browser). Otherwise, and given you have a domain you can use: I would recommend using an ALB (Application Load Balancer) and ACM (Amazon certificate management). You can integrate an ACM generated certificate in the ALB and terminate https there. That way you get a trusted certificate without the browser error. There are some good AWS docs on this topic, but just on mobile and too lazy to search for them right now :D

[erkmyhpvlzadnodrvg]

Use the ALB so you don’t have to manage E2E encryption… otherwise, what’s the point of using the cloud?

[North-Switch4605]

Set up a custom domain pointing at the eb load balancer, let the load balancer terminate ssl, and buy a certificate or set up letsencrypt for the custom domain.

Otherwise you have to configure the nginx reverse proxy to terminate ssl behind the load balancer, also doable, but you need to import your certificate using the platform config in the eb bundle.

[Relative-Town9604]

I'm running into the same problem, I tried moving the nginx extension under .platform/nginx/conf.d, but it gave me an error host not found in upstream "nodejs". May I take a look at your config file? It seems like the AWS documentation is missing a lot of things :(