I am using ubuntu server with vsftpd service, connecting over SSL. When connecting using Filezilla randomly getting below error.
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Failed to retrieve directory listing
It will be okay after restarting vsftpd service and will again showing after some days. tried reinstalling vsftpd service and regenerated certificate.
Here is my /etc/vsftpd.conf`
rsa_private_key_file=/etc/ssl/private/vsftpd.key
rsa_cert_file=/etc/ssl/private/vsftpd.pem
ssl_ciphers=HIGH
pasv_enable=YES
pasv_max_port=12110
pasv_min_port=12099
port_enable=YES
pasv_address=<ip>
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=NO
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
allow_writeable_chroot=YES
pasv_promiscuous=YES
I have tried both active and passive mode and using ec2 instance and ports are opened on security groups. Tried same time different ISP ips and different location( not a local firewall issue).
Added the line seccomp_sandbox=NO on /etc/vsftpd.conf file solved my issue.
Related
I am new to HTTPs. In our application to integrate with another system we were given HTTPs URLs along with their certificates. Our team added those certificates in the test store. Now when we are sending request on those URLs, we are getting “Unsupported or unrecognized SSL message”.
And if I do curl -v on that URL, I get error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
Both of these errors are due to the same reason?
It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client.
With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
If this is exact the URL you are supposed to use (i.e. no simply changing of http:// to https:// on your site) then it is likely a server side problem. But it might also be a problem of some middlebox or software in the network path to the server, like some antivirus, firewall or captive portal hijacking your data and denying access to the remote system with an error message.
In my case, I had on apache2 another badly configured virtual host. On the other wrong virtual host there was a http virtual server on port 443!!!
The second virtual host was correct but apache cannot use different protocols on the same port for different virtual hosts.
After removing the http on port 443 configuration all other https hosts worked and error
error:1408F10B:SSL routines:ssl3_get_record:wrong version number"
disapeared
I am building an ecommerce website on a local Windows 7 pro (Apache/php) test server with a self-signed SSL. I have the mydomain.com in the hosts file redirecting to localhost - so far so good.
When I try to use the email function of the ecommerce software via Gmail smtp, I am getting an SSL error:
[23-Apr-2018 03:00:06 America/New_York] Connection failed. Error #2: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed [C:\Apache24\htdocs\includes\classes\vendors\PHPMailer\class.smtp.php line 379]
[23-Apr-2018 03:00:06 America/New_York] SMTP Error: Could not connect to SMTP host.
[23-Apr-2018 03:00:06 America/New_York] CLIENT -> SERVER: QUIT
I thought about just getting a cheap CA SSL and installing it on the server but I'm not sure this will work, since the Gmail smtp server is obviously not using my hosts file. This is just a guess at this point.
Question I'd like answered is, 1, will installing CA cert resolve the issue, and 2. if not, what is your strategy to have a functional email on a test server with domain in hosts file?
Thank you,
David
I added the following to the function responsible for smtp connection. Warning, only to be used on completely secure environment, your own test server, never on a live server.
$options["ssl"]=array("verify_peer"=>false,"verify_peer_name"=>false,"allow_self_signed"=>true);
I installed : "cpan isntall Crypt::SSLeay" So the error from "fs.cgi: ERROR 500 SSL negotiation failed:" Changed to "
failed while requesting fs.cgi: SSL negotiation failed: at /usr/local/share/perl5/LWP/Protocol/http.pm line 25 at /usr/local/share/perl5/LWP/Protocol/http.pm line 25
"
How to fix this? I searched this forum but the issue is still there. I have two servers first server is accessing the server 2, both have different ssl certificates.
Apache on CentOS 6. Please explain the solution properly.
This issue was fixed by opening port 443 on both servers.
This error occurs due to problem in SSL. Some SSL certificates won't be enabled to cover the emails. Or in your server the devocot or imap was not installed to connect SSL. I experience the same problem and its fixed by simply turning off the SSL or make it to TLS to connect the email it fixed. May be this solution help someone in future
I am having issue connecting to a qmgr. the host rejected connection due to cipherspec error for ssl channel on port 1414. The keystore checked out ok. I was able to use openssh to connect to the host and retrieve its keys.
I have tried to enable and disable sslv3. I provided keystore password with and without "" (double quotes). These are connection properties
qcf=wmq://aftbusu105.it.companyx.com:1414/?qmgr=MQPLTC010,channel=FUSION.SSL,sslCipherSuite=SSL_RSA_WITH_NULL_MD5,transportType=1
reqQ=queue:///FUSIONQL.app.queuename.1_0.Q.PS.REQ
rspQ=queue:///FUSIONQL.app.queuename.1_0.Q.PS.REQ
mep=oneway
connCnt=1
sessCnt=1
numMsgs=1
connInterval=10
msgInterval=10
deliveryMode=1
priority=1
expiration=1
keystore=/path/keystore/m36797q.jks
password=a$tilBe2Flower
alias=m36797q
Do you know what the issue could be?
Can you confirm if you have FIPs enabled on either the server or the client? It's possible you are getting error because the ciphersuite
SSL_RSA_WITH_NULL_MD5 is not supported in FIPS mode. Are you seeing any AMQ errors in your QMGR error logs?
Also, let us know the MQ version you are using.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally