I don't believe so. I don't even know how to implement something like that. Unless AWS ec2 containers do that by default.
Could a CORS policy cause an issue? I wrote one myself
Content-Security-Policy:
default-src 'self' undefined;
object-src 'self';
script-src 'self' 'unsafe-eval' 'nonce-5238aeb9-e008-4d1b-8790-23cc12a1ef84' 'unsafe-inline' https://maps.googleapis.com/ https://letsencrypt.org/ /.well-known/acme-challenge/;
style-src 'self' 'unsafe-inline' 'strict-dynamic' https://fonts.googleapis.com/ https://fonts.cdnfonts.com/ http://fonts.gstatic.com; img-src 'self' https://res.cloudinary.com/ https://maps.gstatic.com https://maps.googleapis.com data: w3.org/svg/2000;
font-src 'self' https://fonts.googleapis.com/ https://fonts.cdnfonts.com/ http://fonts.gstatic.com;
base-uri 'self';
EC2 does have "Security Groups" which is a fancy way of grouping firewall/access rules.
That means port 8443 is not encrypted, try:
curl -Ii http://lawrence-sanzogni.com:443/
It seems to return a 200 status
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Security-Policy: default-src 'self' undefined; object-src 'self'; script-src 'self' 'unsafe-eval' 'nonce-6fe600f7-3237-4ffe-bac0-dba30b3fe427' 'unsafe-inline' https://maps.googleapis.com/ https://letsencrypt.org/ /.well-known/acme-challenge/; style-src 'self' 'unsafe-inline' 'strict-dynamic' https://fonts.googleapis.com/ https://fonts.cdnfonts.com/ http://fonts.gstatic.com; img-src 'self' https://res.cloudinary.com/ https://maps.gstatic.com https://maps.googleapis.com data: w3.org/svg/2000; font-src 'self' https://fonts.googleapis.com/ https://fonts.cdnfonts.com/ http://fonts.gstatic.com; base-uri 'self';
Access-Control-Allow-Origin: *
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Fri, 24 Mar 2023 17:50:54 GMT
ETag: W/"2f5-18714beb084"
Content-Type: text/html; charset=UTF-8
Content-Length: 757
Vary: Accept-Encoding
Date: Thu, 16 Nov 2023 01:33:04 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Because it is doing HTTP.
NOT HTTPS.
Apologies.
Same error message as before
$ curl -Ii https://lawrence-sanzogni.com:443/
curl: (35) error:0A00010B:SSL routines::wrong version number
when I run it on port 8443 it times out
$ curl -Ii https://lawrence-sanzogni.com:8443/
curl: (28) Failed to connect to lawrence-sanzogni.com port 8443 after 131072 ms: Connection timed out
Is there a "front end" to that?
OR
Is that going to be serving the Internet directly?
It does indeed have a front end, here is the source code: https://github.com/Lawsan92/portfolio
The website uses react-router-dom for the front end, which enables client-side routing.
So, who/what is the first to hear requests to: https://lawrence-sanzogni.com/
The server in the server.js file . The root / endpoint will always send the request to the http server created in that file and - theoretically to the https server as well.
Here is the source code for those servers: https://github.com/Lawsan92/portfolio/blob/main/server/server.js
Please stop posting your source code - this is not a place for that.
I apologize. But in essence all requests should first be heard by the routers created in the backend code.
The most likely problem is that your port forwarding from 443 to 8443 is unsuccessful. You mentioned you weren't the root user which implies someone else is, so they may have setup 443 already (and even incorrectly), or something could be preconfigured.
Either way, the public port 443 is pointing (either directly or via port forwarding) to an http listener, not https. If you point to an invalid file or one your node server process doesn't have permission to read, will the https service start at all? Check all your port forwarding - port 443 won't magically point to an http listener as by default there would be no listener at all unless something is set up.
I'd suggest pointing to the key and fullchain.pem (as the cert), skip using ca.pem as it's unnecessary if using the full chain.
To debug:
- Start your node server
- On the same machine use curl to request https://localhost:8443 (or whatever port you bind your https listener to). This should succeed, if not fix this first.
- If the previous step works, proceed to debug why external access is not routing port 443 to your listener port.
So I feel like a dummy 
I wrote all the port redirects...and these are all of them
$ sudo iptables -t nat -L --line-numbers -n | grep REDIRECT
/*
1 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3000
2 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 3000
3 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 8080
4 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 8080
5 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 8080
- So not only was port:443 was being redirected to 8080 instead 8443 BUT it was also being redirected to port:3000 for some reason....so I've been redirecting requests to the both the wrong HTTP port number but also to the port number that my HTTP server was running on...
Needless to say that this was a learning experience and I'd like to thank everyone who's helped me. I deleted all the unnecessary port forwardings and now my site is up and running and my issue resolve.
thank you all again @webprofusion @rg305 @MikeMcQ
Glad you found the fix!