For some unknown reason, there was a problem with uploading files (any) through the web form. After submitting form, the browser displays an error message with the code PR_CONNECT_RESET_ERROR. If I try to download a file over a normal connection (http), then everything is fine, no problem. Also no problem if, for example, I upload a picture (4Kb).
I hope for your help and thanks in advance!
.
My domain is: teboil.com.ua
I ran this command: POST HTTP-request multipart/form data
It produced this output: PR_CONNECT_RESET_ERROR
My web server is (include version): Apache/2.4.39
The operating system my web server runs on is (include version): CentOS 7.9.2009
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): CentOS Web Panel 0.9.8.1039 (free edition)
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AND a.country = "" ORDER BY institution_name asc ,id ASC LIMIT 20' at line 6 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AND a.country = ""' at line 6 Please try one of the following pages: Home Page
Such an error may interrupt / reset the connection.
PPS: And why are such errors public visible?
Looks like it is possible to hack your database with Sql injections.
Never, never, never publish such informations. And a script, that accepts Sql-injections -> throw it away.
So your https configuration may be buggy. But that's not a certificate problem.
My configuration is okay.
So you know the https handling of that script is buggy.
It's not just this one script. All forms with enctype="multipart/form-data" and which upload files of any size(even 1 kb), that used to work before, suddenly stopped working yesterday. I hadn't changed anything on my server. I am the only one with root access.
Let me continue looking for a solution, but I have a feeling you will hear about this more in the coming days.
But that buggy configuration doesn't explain the PR_RESET.
PS: Why do you hide public visible informations? Your certificate and your wrong chain are worldwide visible. Hiding such informations is a little bit curious.
Maybe you recommend configuration SSL? My configuration now (ssl.conf):
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA!RC4:EECDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
I don't see how those SSL/TLS settings could cause such an error.
Does this error occur for every client? Or just a few? On the internet, I saw a few threads mentioning anti virus software like Avast or others causing this error.
It also might be some kind of MTU problem. Not an issue when the packets are small, but causing issues when the TCP packets are fully loaded.
File size greater 1 kb -> use GZIP. May be that's buggy.
Or the script throws an unhandled exception, so the Content-length in the header and the content-length of the page don't match.
PPS: If it would be a real SSL / certificate problem, an upload of a 5 byte file would be affected. But that works -> so it's a script- or configuration problem.
It actually does. Try using Wireshark, I just did that. When sending a file (1 MB in my case), the server accepts the HTTPS connection and it even acknowledges (through TCP "ACK" packets) multiple parts of the file being send. However, after 17 ACK packets, your server just suddenly, during the transfer of the file, sends a TCP RST packet!
Also something I noticed what is different between the HTTP and HTTPS packet dump: with the HTTP packets, your server actually acknowledges the received TCP packets in order. I.e., my host sends packets 1, 2, 3 and 4, your server correctly acknowledges packets 1, followed by packet 2, followed by packet 3 and so on. However, when using HTTPS, your server skips packets when acknowledging the received packets! It jumps from packet 1 to 3 to 6 to 8 to 10. Very strange behaviour.
In any case, it's your server causing the disconnect after a few kilobytes of received data.
If I send a small file, Wireshark tells me the server will again acknowledge in the strange way, skipping one packet every time, but now it actually does "recognise" the last received packet as being the last, as it closes the TCP connection server-side with a correct FIN/ACK packet. It however "forgets" to send any HTTP response what so ever, so CURL complains about an "Empty reply from server".
In any case, something is terribly wrong with the server side network stack on port 443. Perhaps the TLS library used, perhaps something OS-related, I don't know.
I think however it's almost certainly not something certificate related.