EC2 Instance https requests not working

0

So, I have a godaddy domain and I have created a subdomain also.

This subdomain is pointing to a node app which is hosted on an EC2 instance. This app is running on port 9999 of an elastic IP, but I am using nginx as a reverse proxy to send all port 9999 traffic to port 80 (http).

The app communicates with a backend server via http requests. This was all running fine without https. I could access the app correctly through the godaddy subdomain and could communicate with the backend.

I then set up https for the godaddy subdomain. I could still access the app from the https subdomain, but cannot communicate with the backend. The backend settings have been changed to be https.

I'm not sure if the issue is in godaddy or aws or nginx or the backend or the node app itself, but looking for some assistance on where to look. Do I need to setup an ssl certificate for the ec2 instance, as well as the godaddy subdomain?

asked 10 months ago729 views
2 Answers
0

My guess is that there is no problem with godaddy's domain.
I thought it was probably an AWS or Nginx setting.
Can you first check the Nginx access log and error log and share any errors?

profile picture
EXPERT
answered 10 months ago
  • This is the error logs from today:

    2023/07/02 06:13:23 [warn] 725787#725787: *10448 an upstream response is buffered to a temporary file /var/lib/nginx/tmp/proxy/1/07/0000000071 while reading upstream, client: 192.88.134.39, server: _, request: "GET /src/assets/style/index.scss HTTP/1.1", upstream: "http://127.0.0.1:9999/src/assets/style/index.scss", host: "tagmanager.nodex.au", referrer: "https://tagmanager.nodex.au/src/main.ts" 2023/07/02 06:31:22 [warn] 725787#725787: *10601 an upstream response is buffered to a temporary file /var/lib/nginx/tmp/proxy/2/07/0000000072 while reading upstream, client: 124.189.4.167, server: _, request: "GET /node_modules/.vite/deps/@arco-design_web-vue_es_icon.js?v=f800d754 HTTP/1.1", upstream: "http://127.0.0.1:9999/node_modules/.vite/deps/@arco-design_web-vue_es_icon.js?v=f800d754", host: "13.239.80.106", referrer: "http://13.239.80.106/src/main.ts" 2023/07/02 06:31:22 [warn] 725787#725787: *10600 an upstream response is buffered to a temporary file /var/lib/nginx/tmp/proxy/3/07/0000000073 while reading upstream, client: 124.189.4.167, server: _, request: "GET /node_modules/@arco-design/web-vue/dist/arco.css HTTP/1.1", upstream: "http://127.0.0.1:9999/node_modules/@arco-design/web-vue/dist/arco.css", host: "13.239.80.106", referrer: "http://13.239.80.106/src/main.ts" 2023/07/02 06:31:22 [warn] 725787#725787: *10607 an upstream response is buffered to a temporary file /var/lib/nginx/tmp/proxy/4/07/0000000074 while reading upstream, client:

  • Thanks for sharing the log. Warnings are showing, but no errors seem to be present. By the way, are there any errors when you try to access the backend?

  • Apologies, I didn't realise but the logs didn't all copy across. See the error below:

    2023/07/02 06:31:47 [error] 1069425#1069425: *2 SSL_do_handshake() failed (SSL: error:0A00010B:SSL routines::wrong version number) while SSL handshaking to upstream, client: 124.189.4.167, server: _, request: "GET /poweredby.png HTTP/1.1", upstream: "https://127.0.0.1:9999/poweredby.png", host: "13.239.80.106", referrer: "http://13.239.80.106/"

  • Also, no there are no errors when accessing the backend. The site just gets no response from the looks of it

  • Thank you for sharing. As far as that error is concerned, I still think there is a problem with the Nginx configuration. I think "http://13.239.80.106/" is the IP address of the backend, but it appears to be accessed via HTTP. Your assumption is that access to the backend is HTTPS. Is it possible to have you share the configuration file where you are setting up the proxy?
    I found a similar question on StackOverflow. Please read it once, maybe it will help. https://stackoverflow.com/questions/38931468/nginx-reverse-proxy-error14077438ssl-ssl-do-handshake-failed/38957403

0

I thought the error might be due to the fact that the certificate was not configured in the settings that are listening on HTTPS.
You would need to configure the certificate as follows.
The certificate path should be changed to match the location where it is placed.

server {
    listen       80;
    listen       [::]:80;
    server_name  _;

    location / {
       proxy_pass http://localhost:9999;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
    }

    server {
    listen  443;
    listen  [::]:443;
    server_name _;
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    location / {
            proxy_pass http://localhost:9999;
            proxy_ssl_server_name on;
    }
    }
profile picture
EXPERT
answered 10 months ago
  • Hi Riku,

    The backend is separately hosted altogether and I don't have access to the hosting of this. The backend is accessed from the node app through http requests.

    So I need to configure the certificate in the ngninx config. Is this a separate certificate to the one for my godaddy domain. Or the same one? I thought that if I have a ssl certificate for my godaddy domain that is pointing to my ec2 instance, I only need to have a certificate at the domain level?

  • However, the logs appear to be accessed using HTTPS, as shown here. This led me to believe that a certificate needed to be set up.

    "https://127.0.0.1:9999/poweredby.png"

    I think you need to import the ssl certificate for the godaddy domain into EC2.

  • So should I remove the ssl certificate from my godaddy domain and import it into my ec2 instance? Or keep the ssl certificate on my godaddy domain and just put the details into the nginx config?

  • If you have created an SSL certificate on the same domain as EC2, there should be no problem if you import it as is.

  • Hi Riku,

    I have added ssl certificate into my nginx config and issue is still not resolved. See config below:

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions