# SSL\_do\_handshake() failed (SSL: error:0A00006C

**URL:** <https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007>\
**Category:** Help\
**Created:** [June 12, 2024, 5:46pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007 "2024-06-12T17:46:32Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![cyned](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cyned/32/80642_2.png) [@cyned](https://community.letsencrypt.org/u/cyned)\
**Post date:** [June 12, 2024, 5:46pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/1 "2024-06-12T17:46:32Z")

</div>

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](https://crt.sh/?q=example.com)), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: [https://outdoors.rest](https://outdoors.rest)

I ran this command: sudo tail -f /var/log/nginx/error.log

It produced this output: 2024/06/12 14:50:10 [crit] 111675#111675: \*1483 SSL\_do\_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 165.154.129.188, server: 0.0.0.0:443

My web server is (include version): nginx/1.22.0 (Ubuntu)

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is: digitalOcean

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot): certbot 2.11.0

---

<div class="post-metadata">

**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\
**Post date:** [June 12, 2024, 6:05pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/2 "2024-06-12T18:05:25Z")

</div>

Welcome to the community @cyned

I don't have any problem making the TLS (SSL) connection to your domain ([see this link](https://decoder.link/sslchecker/outdoors.rest/443)). 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.

```nohighlight
curl -i https://outdoors.rest

HTTP/1.1 502 Bad Gateway
Server: nginx/1.22.0 (Ubuntu)
Date: Wed, 12 Jun 2024 17:59:57 GMT
Content-Type: text/html
Content-Length: 166
Connection: keep-alive

```

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [June 12, 2024, 6:47pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/3 "2024-06-12T18:47:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 12, 2024, 9:29pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/4 "2024-06-12T21:29:43Z")

</div>

What caused this?

This is an OpenSSL error that bubbled up into Nginx and can be caused by many things.

I have usually only seen it raised in two circumstances:

- A configuration error or internal cache issue, which applies to all connections.
- A protocol or other mismatch with a client, which only applies to select connections.

Looking at SSL Labs analysis - [SSL Server Test: outdoors.rest (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/analyze.html?d=outdoors.rest) - there are handshake failures from a handful of legacy clients:

- [Chrome 49 / XP SP3](https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP%20SP3&key=136)
- [Safari 6 / iOS 6.0.1](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=6&platform=iOS%206.0.1&key=33)
- [Safari 7 / iOS 7.1](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=7&platform=iOS%207.1&key=63)
- [Safari 7 / OS X 10.9](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=7&platform=OS%20X%2010.9&key=35)
- [Safari 8 / iOS 8.4](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=8&platform=iOS%208.4&key=85)
- [Safari 8 / OS X 10.10](https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=8&platform=OS%20X%2010.10&key=87)

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.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 12, 2024, 9:36pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/5 "2024-06-12T21:36:17Z")

</div>

> [@MikeMcQ](#):
>
> Sometimes it just means some ill-behaved client (like a bot) made an invalid request.

IMHO, this is probably the reason.

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.

---

<div class="post-metadata">

**Author:** ![cyned](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cyned/32/80642_2.png) [@cyned](https://community.letsencrypt.org/u/cyned)\
**Post date:** [June 12, 2024, 10:06pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/6 "2024-06-12T22:06:19Z")

</div>

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!

````nohighlight
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

}```
````

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 12, 2024, 10:38pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/7 "2024-06-12T22:38:15Z")

</div>

> [@cyned](#):
>
> The problem I'm having is connecting to stripe webhooks.

I think the issue is likely due to a mix of your OpenSSL install and something in one of these two files:

```nohighlight
    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/](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 packages](https://nginx.org/en/linux_packages.html#Ubuntu) _i 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.

---

<div class="post-metadata">

**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\
**Post date:** [June 12, 2024, 10:49pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/8 "2024-06-12T22:49:31Z")

</div>

> [@cyned](#):
>
> The problem I'm having is connecting to stripe webhooks.

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.

```nohighlight
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)

```

---

<div class="post-metadata">

**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\
**Post date:** [June 12, 2024, 11:12pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/9 "2024-06-12T23:12:38Z")

</div>

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](https://docs.stripe.com/security/guide#tls) v1.3.

---

<div class="post-metadata">

**Author:** ![Rip](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rip/32/70863_2.png) [@Rip](https://community.letsencrypt.org/u/Rip)\
**Post date:** [June 13, 2024, 12:44am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/10 "2024-06-13T00:44:08Z")

</div>

> [@MikeMcQ](#):
>
> Stripe webhooks don't support TLS 1.3

Stripe supports up to TLS 1.2 as of writing this.

> **[Webhooks: how to investigate and fix "Connection to remote host denied" :...](https://support.stripe.com/questions/webhooks-how-to-investigate-and-fix-connection-to-remote-host-denied)**
>
> Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 13, 2024, 1:02am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/11 "2024-06-13T01:02:26Z")

</div>

> [@MikeMcQ](#):
>
> I'm not sure but since Stripe webhooks don't support TLS 1.3 I wonder if they support ECDSA certs.

Wow, that’s a nice catch. Even if this ends up not being the cause, I’m really impressed you picked up on that being a possibility.

---

<div class="post-metadata">

**Author:** ![cyned](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cyned/32/80642_2.png) [@cyned](https://community.letsencrypt.org/u/cyned)\
**Post date:** [June 13, 2024, 1:34pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/12 "2024-06-13T13:34:12Z")

</div>

wow thanks everyone! I'll circle back to stripe about TLS version.

---

<div class="post-metadata">

**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\
**Post date:** [June 13, 2024, 1:46pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/13 "2024-06-13T13:46:06Z")

</div>

> [@cyned](#):
>
> I'll circle back to stripe about TLS version.

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

---

<div class="post-metadata">

**Author:** ![Rip](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rip/32/70863_2.png) [@Rip](https://community.letsencrypt.org/u/Rip)\
**Post date:** [June 13, 2024, 11:38pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/14 "2024-06-13T23:38:25Z")

</div>

> [@cyned](#):
>
> I'll circle back to stripe about TLS version.

It would be great to hear the results. ;@)

---

<div class="post-metadata">

**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\
**Post date:** [June 13, 2024, 11:51pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/15 "2024-06-13T23:51:01Z")

</div>

165.154.129.188 isn't in stripe webhook origin IP they posted:

> **[Domains and IP addresses](https://docs.stripe.com/ips#webhook-notifications)**
>
> Ensure your integration is always communicating with Stripe.

> ### Webhook notifications
> 
> The full list of IP addresses that webhook notifications may come from is:

```nohighlight
3.18.12.63
3.130.192.231
13.235.14.237
13.235.122.149
18.211.135.69
35.154.171.200
52.15.183.38
54.88.130.119
54.88.130.237
54.187.174.169
54.187.205.235
54.187.216.72

```

---

<div class="post-metadata">

**Author:** ![Rip](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rip/32/70863_2.png) [@Rip](https://community.letsencrypt.org/u/Rip)\
**Post date:** [June 14, 2024, 12:20am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/16 "2024-06-14T00:20:44Z")

</div>

Yeah... But

> [@orangepizza](#):
>
> 165.154.129.188

I don't see the connection...  
The IP is alive but as far as I can tell is not associated with:

```nohighlight
A records for outdoors.rest: ['45.55.132.45']

```

Might be wrong... I don't see the connection, but I am sorta blind. Please enlighten me.

---

<div class="post-metadata">

**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\
**Post date:** [June 14, 2024, 12:25am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/17 "2024-06-14T00:25:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [June 14, 2024, 4:06am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/18 "2024-06-14T04:06:57Z")

</div>

> [@orangepizza](#):
>
> 165.154.129.188 isn't in stripe webhook origin IP they posted:

That's because it has nothing to do with Stripe.  
It's a known/listed hacker/scanner IP.

So...  
This has nothing to do with the `webhook` problem:

> [@cyned](#):
>
> I ran this command: sudo tail -f /var/log/nginx/error.log
> 
> It produced this output: 2024/06/12 14:50:10 [crit] 111675#111675: \*1483 SSL\_do\_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 165.154.129.188, server: 0.0.0.0:443

---

<div class="post-metadata">

**Author:** ![linkp](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/linkp/32/60089_2.png) [@linkp](https://community.letsencrypt.org/u/linkp)\
**Post date:** [June 14, 2024, 4:33am UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/19 "2024-06-14T04:33:48Z")

</div>

> [@rg305](#):
>
> It's a known/listed hacker/scanner IP.

So it is!

[https://www.abuseipdb.com/check/165.154.129.188](https://www.abuseipdb.com/check/165.154.129.188)

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [June 14, 2024, 4:44pm UTC](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007/20 "2024-06-14T16:44:39Z")

</div>

> [@rg305](#):
>
> That's because it has nothing to do with Stripe.  
> It's a known/listed hacker/scanner IP.

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!

[Next page](https://community.letsencrypt.org/t/ssl-do-handshake-failed-ssl-error-0a00006c/220007.md?page=2)