Getting this error message when trying to run composer install Task in Trellis. Deleting my composer.lock file then trying to manually run composer install --verbose on client gives the following error ouput:
[Composer\Downloader\TransportException]
curl error 35 while downloading https://{mydomain}/satispress/packages.json: error:14094458:SSL routines:
ssl3_read_bytes:tlsv1 unrecognized name
Not sure what’s wrong here both client and server are provisioned with Trellis and I’ve also whitelisted the staging server’s IP address for bothh inbound TCP and UDP.
Thanks for replying! I’ve been banging my head on this one. I deleted all my release and tried to redeploy and got the same error. Then I tried to just go into the staging server and run curl https://alliancechemical.com/satispress/packages.json and I got the same error. So now I’ve at least nailed it down to being an issue with curl. I can download the contents of that URL on my local machine too so the problem is specific to that staging server. I updated all my packages and rebooted the server and ssh’d back in and got the same error when trying to curl that url. Not sure where to go from here, I’ll read those docs you sent.
It is rather the curl package/command itself that has/uses an outdated SSL library.
What versions are listed on the system with the issue from curl --version?
Edit: As composer uses the PHP curl extension: Check in the phpinfo what OpenSSL version is used by the curl PHP extension.
I also have firewall rules set up on alliancechemical.com server to accept inbound IP ranges from cloudflare and also from the staging server IP address for IPv4. Do you think this could be causing it?
Even doing curl -k https://alliancechemical.com/satispress/packages.json with -k flag returns th error: curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
Try curl --ipv4 https://alliancechemical.com/satispress/packages.json, does this help?
Edit: Added the missing .json part to the command.
dig A alliancechemical.com results in this for me:
alliancechemical.com. 0 IN A 172.67.74.116
alliancechemical.com. 0 IN A 104.26.8.168
alliancechemical.com. 0 IN A 104.26.9.168
and dig AAAA alliancechemical.com:
alliancechemical.com. 0 IN AAAA 2606:4700:20::681a:8a8
alliancechemical.com. 0 IN AAAA 2606:4700:20::ac43:4a74
alliancechemical.com. 0 IN AAAA 2606:4700:20::681a:9a8
Hmm, CloudFlare is used in front of the server.
curl -L -H "Host: alliancechemical.com" 172.67.74.116 works for me, also for the other IPv4 addresses. Edit: This would let curl use HTTP instead of HTTPS, so not a very useful command…
Do you get the same results, or is there something wrong with e.g. the /etc/hosts file?
I’m getting the curl (35) error even when I curl https://alliancechemical.com from staging server. Here’s the results of the commands you did when I did them on staging server:
curl --ipv4 https://alliancechemical.com/satispress/packages.json curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
dig A alliancechemical.com
; <<>> DiG 9.16.1-Ubuntu <<>> A alliancechemical.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;alliancechemical.com. IN A
;; ANSWER SECTION:
alliancechemical.com. 0 IN A 127.0.1.1
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Jan 25 16:46:07 UTC 2023
;; MSG SIZE rcvd: 65
Add --trace ./some-logfile to the curl command, this should also show the TLS/SSL handshake process and what goes wrong.
Alternative, openssl (client command) can be used for debugging the HTTPS connection (How to debug SSL handshake using cURL? - Stack Overflow).
What if the HTTP server doesn’t listen on 127.0.0.1, but only on the public IP address(es)? This may result in an issue when connecting. But you noted that you have the same issue outside of the staging system, where the IP doesn’t resolve to 127.0.0.1, so this is probably not the explanation.
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
# /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 alliancechemical.com alliancechemical
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
It is rather the 
