SoapClient Error in PHP on EC2 AWS server - php

Question

I am tearing my hair out with this problem.
So I have a PHP app which I am moving from a "personal" server to an AWS-EC2.
I have everything installed on the AWS-EC2 server. Apache2, PHP 7.3, MySql etc.
I am testing the app before making the jump, and when testing SoapCliet call I get the following PHP error:
WSDL SOAP-ERROR: Parsing WSDL: Couldn t load from "https://celcer.sri.gob.ec/comprobantes-electronicos-ws/RecepcionComprobantesOffline?wsdl"
I look into the error trying to debug the problem and try a wget call and I get this:
$ sudo wget https://celcer.sri.gob.ec/comprobantes-electronicos-ws/RecepcionComprobantesOffline?wsdl
--2019-04-24 14:29:58-- https://celcer.sri.gob.ec/comprobantes-electronicos-ws/RecepcionComprobantesOffline?wsdl
Resolving celcer.sri.gob.ec (celcer.sri.gob.ec)... 186.42.213.26
Connecting to celcer.sri.gob.ec (celcer.sri.gob.ec)|186.42.213.26|:443... connected.
Unable to establish SSL connection.
Then I try a cURL call:
$ sudo curl -v https://celcer.sri.gob.ec/comprobantes-electronicos-ws/RecepcionComprobantesOffline?wsdl
Trying 186.42.213.26...
TCP_NODELAY set
Connected to celcer.sri.gob.ec (186.42.213.26) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
(304) (OUT), TLS handshake, Client hello (1):
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to celcer.sri.gob.ec:443
stopped the pause stream!
Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to celcer.sri.gob.ec:443
Then I try openSSL:
$ sudo openssl s_client -connect celcer.sri.gob.ec:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 319 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Versions of stuff:
Ubuntu Linux 18.04.2
PHP 7.3
OpenSSL 1.1.1b 26 Feb 2019
I have been searching for an answer for days with no solution.
Obviously, all these commands work perfectly on my old server (not EC2) although Ubuntu's version is 16.04.1 and OpenSSL is 1.0.2g. I also installed OpenSSL 1.1.1b (to check if it was a version issue) for windows on my pc with a successful connection to the mentioned site.
I have tried with no success or change whatsoever:
-Disabling IPv6
-Using additional options like -servername or a specific protocol
-Specifying the server IP on hosts file
-Restarting
-Updating
-Updating CA certificates
-Fiddling with the firewall (both servers firewall are equally configured)
I must say that this error does not happen in all sites, in fact, I have only found this problem on this particular site celcer.sri.gob.ec which is a local government site and it's useless and futile to even think that they change anything (even if it's badly configured) also this IS the one an only site I need to soap with.
After several hours of reading and probing, I am now desperate. The only difference I can find is that this new server is an AWS EC2 server and some middle layer amazon firewall is causing this problem, but I have no idea how to even debug such a claim. My security group of EC2 just has open port 80 and port 443 for the web server and SSH for a specific IP.
Please Help
Edit 1:
I did try this before, same results:
$ openssl s_client -connect celcer.sri.gob.ec:443 -servername celcer.sri.gob.ec
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 319 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
And yes it does work with several other https sites, for example:
s$ openssl s_client -connect stackoverflow.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 C = US, ST = NY, L = New York, O = "Stack Exchange, Inc.", CN = *.stackexchange.com
verify return:1
---
Certificate chain
0 s:C = US, ST = NY, L = New York, O = "Stack Exchange, Inc.", CN = *.stackexchange.com
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
---
Server certificate, etc, etc....
Edit 2:
So as I continue to fiddle around this and since with every passing minute I am convinced this has AWS Issue written all over the place I went to my AWS account created a security group allowing ALL inbound and outbound traffic and launched a fresh new Ubuntu instance, as soon as I logged in I went and try openssl, first with any secure site and then with the mentioned site and SAME RESPONSE on both cases, one successful one errno=104.
Then launched another fresh new instance this time with Amazon Linux on it, first thing after login and boom SAME RESPONSE on both cases, one successful one errno=104.
This is interesting cause I now can almost be certain it is not a configuration of my server, but a block on some firewall between amazon and celcer.sri.gob.ec. The question is how could I find this out, networking is the lesser of my IT skills.
Please help.

Answer 1

Although we may never find out what was causing the problem, I followed the suggestion of the AWS forum member, who found that the solution was to move to another AWS region. Somehow, somewhere the government server I needed to communicate with was breaking the communication to the specific original region I chose to launch my instance.
I chose another region, and problem solved.