It’s a bit of a niche technical one this but as I’ve had several reports of it recently I wanted to share this one with you in case it helps.
If you’re an MDaemon customer you may have started to see the following errors in the SMTP (Out) logs when trying to send email to some specific external hosts…
“SSL negotiation failed*,*error code 0x80090326”
What this boils down to is an issue where MDaemon and the remote SMTP server cannot find a common set of SSL ciphers that they both have available to use.
Why would this start to happen on my server?
Due to the higher security of the AES cipher, some email servers are now starting to only accept SSL sessions using it, and therefore only advertise those ciphers at the start of an SSL session.
MDaemon uses the Microsoft Schannel library for its SSL/TLS support and so can only use the SSL Ciphers provided by that library. Microsoft added support for AES ciphers in Windows Vista but earlier Windows Operating systems like Windows XP and Server 2003 do not include them.
Microsoft have created a hotfix that adds AES Cipher support which has been confirmed to fix the issue specifically for Server 2003.
Unfortunately no equivalent fix exists for Windows XP or SBS 2003
Due to the end of life of XP and Exchange 2003 (included in SBS 2003) I think it is very unlikely there will be one in the future.
Workaround
For the unsupported Windows operating systems the work around is to not use SSL Negotiation for the specific domains that fail.
This can be done buy first finding the recipients domain MX Records and discovering any valid mail hosts that may be used for there domain.
The easiest way we have found to do find these is by using the excellent MXToolbox website
Simply enter the domain of the recipient and make a note of any MX record ‘Hostnames’ that are returned. for example…
We have noticed that a large majority of the examples we have seen are all using the ‘1&1’ mail servers, while this is very common they are not the only examples we have seen so you may still need to look for other examples and add them as well.
Once you know the mail hostnames these can be added to the MDaemon SSL White list which can be found under…
Security -> Security Settings -> SSL & TLS -> STARTTLS White List.
You can see in this example I have added the two 1&1 mail hosts.
Any new SMTP Sessions to those specific hosts will now not use SSL and so should not trigger the error.
Its worth noting that this error should not happen on Windows Vista or newer Operating systems, unless the AES ciphers have been turned off in the registry, which is possible but unlikely.
I get this error when I try to configure the mail settings.
Have you gone to your Google account and enabled IMAP/POP?
Yes, I have.
I’m using ubuntu 12.04 with the imap support for php added in the .ini files.
Same problem. I connected to the email I want to fetch from, using outlook successfully. But I keep getting the above error when using OSTicket.
Hello,
any ideas to solve this problem?
@mariamghalleb
You have PHP’s openssl extension installed/enabled on your server, correct? Also, is port 143 open on your server?
Cheers.
@JediKev yes openssl is enabled.
It seems that IMAP is opened in Mailserver Configuration.
As I mentioned in my issue’s description, the error happened after i changed server.
You said it’s duplicate but i don’t see how the issue above occured so here’s my problem again:
Osticket was on server 1,
the email is hosted in server 2,
everything works fine.
Now, osticket is on server 2 ,
the email is hosted in server2,
and we have this error : TLS/SSL failure for mail.xxxxx.com SSL negotiation failed.
server 2 has openssl and 143 open.
Thank you for your help !
My solution was:
To put the server’s url in the hostname (instad of mail.xxxx.com i did S1.xxxx.com) witth IMAP+SSL and 993 as the port number.
I do not understand. The Ubuntu host file? My POP configuration is mail.dominio.com.ar only POP to port 110. Is not OST compatible with fetching emails by POP?
The error is:
TLS/SSL failure for mail.dominio.com.ar: SSL negotiation failed
@newronas1 The error that you are getting says that the SSL/TLS negotiation failed. Why did it fail? Aren’t sure. Since you haven’t told us what version of osTicket you are running, or anything else about your setup, or your configuration settings there isn’t really much anyone here can do to help you. This thread appears to be about IMAP and you are not using IMAP.
You might want to check your mail server logs to see if there is an error logged there and see if it helps clarify what your issue is.
On a side note port 110 is not POP3’s SSL/TLS port. Port 995 is usually POP3 SSL/TLS. So unless your mail server is configured to use SSL/TLS on a the standard unencrypted port that might be your problem.
Either way this seems to me a question about how to configure osTicket and not bug report.
Hi ntozier
Thanks for your answer. The information is:
Versión osTicket v1.10.4 (
035fd0a
)
Software de Servidor Web Apache/2.4.29 (Ubuntu)
Versión MySQL 5.7.25
Versión PHP 7.0.33-5+ubuntu18.04.1+deb.sury.org+1
I not want to use IMAP. I want to use POP without security, port 110.
My server does not support security, for this reason I want to configure it using POP110. But I have that error that I attached an image.
[cid:image001.png@01D4E64D.13654060]
It seems that if or if you are looking for emails safely, can I disable this option?
Thanks
NR
De: ntozier <notifications@github.com>
Enviado el: jueves, 28 de marzo de 2019 23:30
Para: osTicket/osTicket <osTicket@noreply.github.com>
CC: Julian Talin <julian.talin@vaix.com>; Mention <mention@noreply.github.com>
Asunto: Re: [osTicket/osTicket] SSL negotiation failed on mail configuration (#1132)
@newronas1<https://github.com/newronas1> The error that you are getting says that the SSL/TLS negotiation failed. Why did it fail? Aren’t sure. Since you haven’t told us what version of osTicket you are running, or anything else about your setup, or your configuration settings there isn’t really much anyone here can do to help you. This thread appears to be about IMAP and you are not using IMAP.
You might want to check your mail server logs to see if there is an error logged there and see if it helps clarify what your issue is.
On a side note port 110 is not POP3’s SSL/TLS port. Port 995 is usually POP3 SSL/TLS. So unless your mail server is configured to use SSL/TLS on a the standard unencrypted port that might be your problem.
Either way this seems to me a question about how to configure osTicket and not bug report.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1132 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZlGkG13H3PNnqS9w2XLIkbxIxJ_jLpuks5vbXq0gaJpZM4CSlNC>.
Hi, any idea?
Suggestion?
I think it may be forcing if or if ssl, and my mail server does not support. can i force some change in php files?
Thanks,
J
De: Julian Talin
Enviado el: viernes, 29 de marzo de 2019 4:33 p. m.
Para: osTicket/osTicket <reply@reply.github.com>; osTicket/osTicket <osTicket@noreply.github.com>
CC: Mention <mention@noreply.github.com>
Asunto: RE: [osTicket/osTicket] SSL negotiation failed on mail configuration (#1132)
Hi ntozier
Thanks for your answer. The information is:
Versión osTicket v1.10.4 (
035fd0a
)
Software de Servidor Web Apache/2.4.29 (Ubuntu)
Versión MySQL 5.7.25
Versión PHP 7.0.33-5+ubuntu18.04.1+deb.sury.org+1
I not want to use IMAP. I want to use POP without security, port 110.
My server does not support security, for this reason I want to configure it using POP110. But I have that error that I attached an image.
[cid:image001.png@01D4E8A9.C3E02230]
It seems that if or if you are looking for emails safely, can I disable this option?
Thanks
NR
De: ntozier <notifications@github.com<mailto:notifications@github.com>>
Enviado el: jueves, 28 de marzo de 2019 23:30
Para: osTicket/osTicket <osTicket@noreply.github.com<mailto:osTicket@noreply.github.com>>
CC: Julian Talin <julian.talin@vaix.com<mailto:julian.talin@vaix.com>>; Mention <mention@noreply.github.com<mailto:mention@noreply.github.com>>
Asunto: Re: [osTicket/osTicket] SSL negotiation failed on mail configuration (#1132)
@newronas1<https://github.com/newronas1> The error that you are getting says that the SSL/TLS negotiation failed. Why did it fail? Aren’t sure. Since you haven’t told us what version of osTicket you are running, or anything else about your setup, or your configuration settings there isn’t really much anyone here can do to help you. This thread appears to be about IMAP and you are not using IMAP.
You might want to check your mail server logs to see if there is an error logged there and see if it helps clarify what your issue is.
On a side note port 110 is not POP3’s SSL/TLS port. Port 995 is usually POP3 SSL/TLS. So unless your mail server is configured to use SSL/TLS on a the standard unencrypted port that might be your problem.
Either way this seems to me a question about how to configure osTicket and not bug report.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1132 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AZlGkG13H3PNnqS9w2XLIkbxIxJ_jLpuks5vbXq0gaJpZM4CSlNC>.
This is a very old thread, I can barely remember howto made to work, but I think I tried again some time later and it worked. Be sure to enable imap support in google and also there is something they call «less secure apps» (please google it).
Btw, maybe it is time to close the issue and create a new one.
I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that’s fine. This (I think) indicates that port forwarding and such works.
I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don’t care.
When using svn on mac OS X I get
SSL negotiation failed: SSL error code -1/1/336032856
I’ve found several posts on google about this, but they all say it’s a bug with openssl version 0.9.8, and that using something higher should fix it.
I am currently using openssl 1.0.0c. I have no idea what’s going wrong. I also checked the error log in httpd and nothing comes up.
Any ideas on this would really help.
Thanks
asked Dec 18, 2010 at 0:28
Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.
answered Apr 27, 2011 at 10:15
SamSam
6,2204 gold badges42 silver badges53 bronze badges
1
I received the same error message when my Apache configuration was wrong — my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.
answered Jul 18, 2011 at 13:49
Lukas CenovskyLukas Cenovsky
5,4562 gold badges30 silver badges39 bronze badges
0
I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.
Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).
Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn’t seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:
- 0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
- 0.9.8o (bundled with the latest pysvn, r1360) FAIL
- 0.9.8r (the latest in the 0.9.8 series) FAIL
- 1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
- 0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!
So whatever they fixed in release L got broken again soon after, or there’s something special about CollabNet’s OpenSSL binaries.
answered Nov 21, 2011 at 4:46
Mark ForemanMark Foreman
2,09018 silver badges16 bronze badges
In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing…
It got finally fixed when I replaced the url host name with the ip address of that host.
In existing working copies was enough with:
svn switch --relocate http://hostname.com https://ipaddress
Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.
answered Dec 2, 2011 at 2:44
Fede MikaFede Mika
2,1912 gold badges18 silver badges18 bronze badges
1
I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.
In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.
The full error message(just to enable better google indexing) I receive is:
$ svn ls https://www.OMITTED.dk/svn svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn' svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
In the file /etc/apache2/sites-available/ssl (debian linux)
I added the ServerName as:
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster@localhost
SSLEngine On
ServerName www.OMITTED.dk
answered Jan 11, 2012 at 9:33
See what happens if you eliminate the SSL problem by adding your generated certificate to your client’s trusted certificate store.
answered Apr 27, 2011 at 10:19
8DH8DH
2,00223 silver badges36 bronze badges
One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.
Using Tortoise Subversion 1.6.16, I realise that after execute a «svn checkout https://OMITTED.dk/project», I got the same ssl handshake error.
What I did was
- update c:windowssystem32driversetchosts with «IP_address
OMITTED.dk» - update the entries with the project directory. Edit the
file project/entries and replace the IP_address by OMITTED.dk.
Thus I try the command : svn update path_to_project —non-interactive —trust-server-cert.
Hope will be usefull
answered Jul 11, 2012 at 10:32
I have a very strange problem that I can’t work out what is going on here!
When sending emails to a company that seems to be using Trend Micro Hosting Solution, I can guarantee delivery of the email if my server supports (0x9D) TLS_RSA_WITH_AES_256_GCM_SHA384 cipher suite. However, this does not support perfect forward secrecy.
So when I disable this and all TLS_RSA ciphers, most of the time my mail server gives the message SSL negotiation failed, error code 0x80090326 which means that there is no common protocol between the two mail servers and I have set my server Mdaemon to only send if the connection is encrypted.
As I said, most of the time, it will fail with the above error message, then suddenly it will send using this cipher suite — [C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 which my server supports obviously.
I have looked at the logs and I cannot see anything that would explain why it would repeatedly fail for 80-90% of the time over an hour or two, and then suddenly work using a protocol that we both actually use despite my having changed nothing! If I enable the TLS_RSA cipher suite — the emails send every time without errors. It doesn’t seem to be a difference in host name, ip address or anything obvious like that.
I have tried using this website — https://www.ssllabs.com/ssltest/ Opens a new window to scan their mailserver but this fails to connect so I have no idea what ciphers they are using and more importantly in what order.
I only have this issue with this specific company’s mail server. I have never seen anything where a cipher suite only works sometimes! Either it is allowed or blocked, not sort of working. I have no idea whether this is my side, their side or what could possibly be causing it.
Notice! This document is currently in
Archived
status.
The content of this document may be incorrect or outdated.
Print this article
Full Description: SSL Negotiation Failed: Certification Error: Cert Chain not trusted. Try
adding this certificate database for SSL to succeed Certificate Error:
Unknown and unprovided root certificate. Cause: (-6995)
Cause:
The ECN email certificate has not been accepted as a trusted certificate
by the current Eudora 5.2 personality.
Solution:
You must apply this solution to each personality that you are using.
1) Select the Tools menu and click the personalities option.
2) In the personality window right click the desired personality
and click properties.
3) Click the Incoming Mail Tab.
4) Click the «Last SSL Info» button near the bottom of the
Account settings dialog. If you get an error stating
«You have not received mail using an SSL connection.»,
you must first setup Eudora to send an receive mail. Then,
attempt to retrieve email from the server.
5) You should now see the «SSL Connection Information Manager».
Click the Certificate Information Manager near the
bottom of the dialog.
6) You should now have a display of certificates.
Under Server Certificates, you will see a list of
Server certificates, User trusted Certificates, and
Eudora Provided Trusted Certificates. Under server
certificates, select the Purdue.edu certificate. You
may see a skull and cross bones next to this certificate.
This indicates that you have not yet made this a trusted
certificate. Select this certificate and click the
«Add to Trusted» button. The certificate will now
appear as a User Trusted Certificate.
7) Click Done to close the Certificate Information Manager.
Click OK to close the «Eudora SSL Connection Information
Manager»
9) Click OK to close «Account Settings».
10) Repeat this procedure for each personality you use.
Last Modified:
Dec 19, 2016 11:12 am US/Eastern
Created:
Apr 23, 2007 1:03 pm GMT-4
by
admin
Search the Knowledge Base