OpenSSL Error: wrong version number

[mdrobbins]

System architecture

Mac, ARM64 (M1, M2, etc)

PHP Version

8.1.26, 8.2.14, 8.3.0

Bug description

Brand new to expose but I’m running into an issue trying to share a site on my machine.

When I run expose share or herd share, I get the following error:

Could not connect to the server.
Connection to tls://us-1.sharedwithexpose.com:443 failed during TLS handshake: SSL operation failed with code 1. OpenSSL Error messages: error:0A00010B:SSL routines::wrong version number

I have a new macOS Sonoma installation and a fresh installation of Laravel Herd v1.3.2 installed with php v8.1, 8.2, and 8.3 available.

I’ve installed expose as a global package via composer and I've tried installing as a phar file. Here are things I’ve done based on other issues found in this repo:

• I’ve verified that the php.ini files for each version have an entry for for curl.cainfo and openssl.cafile and that the cacert.pem file exists at that path.
• I’ve verified that my PATH contains valid paths for
  • PHP_INI_SCAN_DIR
  • HERD_PHP_81_INI_SCANDIR
  • HERD_PHP_82_INI_SCANDIR
  • HERD_PHP_83_INI_SCANDIR

Steps to reproduce

No response

Relevant log output

Could not connect to the server.
Connection to tls://us-1.sharedwithexpose.com:443 failed during TLS handshake: SSL operation failed with code 1. OpenSSL Error messages: error:0A00010B:SSL routines::wrong version number

[scuben]

I have a similar error. Also on macos (ARM) (but I guess that is not the issue) using expose 2.6.2:

Could not connect to the server.
Connection to tls://eu-1.sharedwithexpose.com:443 failed during TLS handshake: SSL operation failed with code 1. OpenSSL Error messages: error:0A0003E8:SSL routines::reason(1000)

update: after 30m it's working again for me.

[doylerules85]

hitting this error now too... Uninstalled herd - reinstall - still erroring out
removed expose - reinstalled

`> Using PHP 8.2.15

PHP is using the following php.ini file:
WARNING: No configuration file (php.ini) used by PHP!

Checking Box requirements:
✔ The application requires the version "^8.1" or greater.
✔ The application requires the extension "zlib".
✔ The application requires the extension "json".

[OK] Your system is ready to run the application.

Using auth token: ***
Trying to use custom domain: [my-custom-domain]

Could not connect to the server.
Connection to tls://sharedwithexpose.com:443 failed during TLS handshake: SSL operation failed with code 1. OpenSSL Error messages: error:0A00010B:SSL routines::wrong version number`

Update

Seems with the new update (1.4.1) this is resolved for me!

[stevepop]

I am having similar issues and although I updated to latest version, I am still getting the same error

Could not connect to the server.
Connection to tls://eu-1.sharedwithexpose.com:443 failed during TLS handshake: Connection lost during TLS handshake (ECONNRESET)

I really need this to test my application on a real device without deploying to a remote server. Any way to fix this?

[jtomlinson]

I'm not sure this helps much but I started getting this error again as well. I've narrowed it down to when I'm on my home network. If I hotspot my phone from the same location, then use that hotspot on my laptop this error goes away. I switch back to my home network and the error comes back. I have no issue accessing anything else on the web from this network.

Could not connect to the server.
Connection to tls://us-1.sharedwithexpose.com:443 failed during TLS handshake: SSL operation failed with code 1. OpenSSL Error messages: error:0A00010B:SSL routines::wrong version number

[stevepop]

@jtomlinson The only way I have been able to make this work is to set my DNS to 8.8.8.8. It isn't ideal but it works for me now.

[joecampo]

@jtomlinson @stevepop Gents, I've been debugging this as well. I've noted that I don't have the same problem using us-2 instead of us-1. Curious if you both have the same results as much (assuming you're both US)

[stevepop]

@joecampo I am in the UK. I tried that earlier but it did not work for me.

[joecampo]

Interesting, since I've switched to us-2 I haven't had the issue pop up at all.

[jtomlinson]

@jtomlinson @stevepop Gents, I've been debugging this as well. I've noted that I don't have the same problem using us-2 instead of us-1. Curious if you both have the same results as much (assuming you're both US)

Switching to us-2 seemed to do the trick for me, hopefully it lasts!

[joecampo]

@jtomlinson @stevepop Gents, I've been debugging this as well. I've noted that I don't have the same problem using us-2 instead of us-1. Curious if you both have the same results as much (assuming you're both US)

Switching to us-2 seemed to do the trick for me, hopefully it lasts!

@jtomlinson I've been testing for over a week now and it seems to have fixed it. I'm guessing that something is configured differently server side for that endpoint.

[stevepop]

@jtomlinson @joecampo Unfortunately setting expose to us-1 does not work for me

[mdrobbins]

Been a minute, but switching to us-2 solved the problem for me as well:

expose default-server us-2

[dasundev]

Same issue here. :(