Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I don't have any problem making the TLS (SSL) connection to your domain (see this link). So not sure what the handshake error means. Sometimes it just means some ill-behaved client (like a bot) made an invalid request.
The more serious problem I see is an HTTPS request to your domain fails with an HTTP error 502 Bad Gateway. You should review any proxy statements in your nginx config. The destination of that is likely not operating properly. If you show us the nginx server block for this domain we may offer more specific advice.
Is that IP address 165.154.129.188 from a client complaining about not being able to reach your website? Or did this error just show up in your logs and you're asking what to do with it?
If you want us to provide you with more specific help, you might want to consider mentioning more with what problem/issue you're actually having. The questionnaire is just a bare minimum for us to help you. Usually one would explain a little bit more with regard to the actual issue.
Because from what I'm seeing now, my advice would be: just ignore these kinds of log entries if they are just that: log entries. If visitors/customers complain, well, that's a different story.
That said, your current issue is of a whole other level as Mike explains.
I am not sure any of those are worth supporting these days.
FWIW. This error code has come up on this forum and stack overflow a few times before. Depending on your cause, searching for "0A00006C" may give you a solution or tell you to look on nginx forums. I checked my archive of the nginx mailing list and did not see this code come up. A web search showed some similar codes pop up, but the "fix" was : this is an openssl issue.
The IP is delegated to APNIC (Asia Pacific) and in a block managed by Ucloud Information Technology Hong Kong - which is a China based cloud provider. GeoIP lookups are showing it being in London (but part of Ucloud), which makes me think it's coming out of a UK based exit node in Ucloud's network.
Any one of those things is insignificant, but the totality of those with a ssl error does suggest this is from a botnet.
Hi, thanks for the response! The problem I'm having is connecting to stripe webhooks. Everything's fine on their end so this handshake is what's in the way. Site is built with the MERN stack.
Following is the nginx server block.
Appreciate your help!
server {
index index.html index.htm index.nginx-debian.html;
server_name outdoors.rest www.outdoors.rest;
location / {
proxy_pass http://localhost:5050;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
location /api {
proxy_pass http://localhost:5050/api;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
ssl_certificate /etc/letsencrypt/live/outdoors.rest/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/outdoors.rest/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.outdoors.rest) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = outdoors.rest) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name outdoors.rest www.outdoors.rest;
return 404; # managed by Certbot
}```
I think the issue is likely due to a mix of your OpenSSL install and something in one of these two files:
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
My suggestions:
1- Reach out to stripe about the nginx openssl configuration params they need to see. I could not find them easily online. There is possibly a lack of required support OR a conflict with whatever certbot installed. You can also try tweaking your config using this: https://ssl-config.mozilla.org/ and hopefully something will pass
2- Make sure your ubuntu install is up to date with the latest packages. if you can update openssl and/or nginx - do that.
3- Try switching from the ubuntu nginx package to the one maintained by nginx themselves. Instructions are here: nginx: Linux packagesi think this is built against it's own up-to-date OpenSSL, but I am not sure
4- Try building the openssl package from source, then building nginx against that.
I don't know what those are. Are those the things you proxy to on port 5050?
I am now getting a successful response from HTTPS to your domain. Can you describe more generally what the problem is? Like give an example URL or what steps you try that gives an error. Is it the Stripe webhook that fails to reach this server block? If so I agree you need to reach out to Stripe to check what options they need.
I don't see anything wrong with the nginx config at least as far as this domain and server block goes.
curl -i https://outdoors.rest/api/Test404
HTTP/1.1 200 OK
Server: nginx/1.22.0 (Ubuntu)
Date: Wed, 12 Jun 2024 22:47:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 792
Connection: keep-alive
X-Powered-By: Express
(other headers and data response omitted)
I'm not sure but since Stripe webhooks don't support TLS 1.3 I wonder if they support ECDSA certs. You may need to request an RSA cert and use that. I didn't see anything in the Stripe docs about that nor am I sure it would create that log entry. It's just something we see sometimes.
You also don't support many cipher suites so you could expand those. Again, I'm not sure that would create the log entry you see but it might. @jvanasco had a link for Mozilla's SSL Configurator which can help choose them.
The requirements for Stripe are better asked at Stripe support or a Stripe-focused forum.
From Stripe docs
If you use an HTTPS URL for your webhook endpoint, Stripe validates that the connection to your server is secure before sending your webhook data. For this to work, your server must be correctly configured to support HTTPS with a valid server certificate. Live mode requires HTTPS URLs. Stripe webhooks don’t currently support TLS v1.3.
Stripe supports TLS 1.2 and so does your server. So, it probably won't be just that. But, check whether they support ECDSA certs (in addition to RSA) and if they need certain ciphers that you don't yet include.
They may have access to better info as to why their hook can't reach you. Let us know what you find. Thanks
From my guess he wants to sprite webhook be able to notifiy their webserver so it can react upone someone buys membership, but failing to do so:
webhook is sprite api connect to webserver, not webserver pulling event from stripe server
So my initial thought of it being a botnet was right! @MikeMcQ first suggested it, but looking up the IP data made me confident he was right - a London based exit node of a HongKong clould provider made little sense. I was really surprised to learn it was a Stripe server based on the IP allocation. It makes perfect sense that Stripe is not related now!