Make life easier by reducing the need to flip between apps. If you are using Outlook Web App, Outlook 2013, or Outlook 2016 connected to Office365 or Exchange Server 2013 then be sure to take advantage of this email and contact synchronization add-on. Smartly links emails to your SuiteCRM records and keeps your contacts in sync.
#1667 - Connection to suiteCRM fails for suiteCRM version 7.10.11
I have a demonstration suiteCRM 7.10.11 instance set up using a Turnkey Linux VM. It is fully accessible via a URL from the internet and I can log in to it with an SSL connection from my browser with no problems. It is using a high order port other than 443 for the SSL connection through my firewall. By viewing logs I confirm that my browser (Goolge Chrome 71.0.3578.98) negotiates a TLS 1.3 connection successfully with the server. Because it is a demonstration instance, it is using a self-signed SSL certificate.
I have configured a single-user GrinMark outlook plugin in my office 365 account according to the single user instructions found here: https://store.suitecrm.com/docs/grinmark-outlook-365-addin-for-suitecrm/single-user-installation. I can now access the <>suiteCRM settings pane from an outlook mail item without any issues. On the settings pane I have the connection URL to my suiteCRM server set up with the same URL that I use in my browser up to, but not including, the "index.php?module=Users&action=Login" portion of the URL. I also have the correct password and username for my admin account configured on this pane. I am not using LDAP auth on the CRM server.
When I attempt to test the connection to my suiteCRM server, I get the following error dialog text:
Connection Failed
Connection Failed SugarInfo::Connect. AddIn version: GM.B.Sugar.Soap.SugarWrapperImplSoap:5.1.1.0 Connecting to https://xxxxxxxxxxxxxxxxx/ as admin Error initializing connection: The request was aborted: Could not create SSL/TLS secure channel.
Questions:
1) What limitations/criteria does your product require when establishing an SSL/TLS connection?
2) Does your product support TLS 1.3 connections with self-signed certificates?
3) Do you have any ideas what the problem may be?
4) What additional information should I collect to troubleshoot?
Cam Russell
5 years ago
Correction above. The above should read TLS 1.2, not TLS 1.3 throughout the text.
5 years ago
After additional log file investigation I found that the issue was the SSL Cipher Suite that I was using was not supported by the GrinMark add-in and cloud app. It turns out that this add-in is not compatible with the recommendations for "Cipher Suites and Enforcing Strong Encryption" found here:
https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html
After relaxing the acceptable cipher suite configuration to the default found with the Turnkey suiteCRM VM, my SSL connection to suiteCRM works successfully.
Down the road, as a paying customer we would like to see the Grinmark add-in and underlying cloud application upgraded so that it can support SSL connections that have been configured according the the Apache recommendations for "Cipher Suites and Enforcing Strong Encryption" found at the URL listed above. For the money you are charging, and considering this is a cloud based application, security considerations should be maintained up to date for your product.
5 years ago
Hi Cam,
We'll definitely fix the issue and add support for TLS 1.3. Sorry it took a while to react due to winter holiday season.
Regards, Max
5 years ago
Hi Cam,
Could you please let us know Cipher Suite that you were using initially?
It is now clear we are talking not about TLS 1.3 which is not released yet, but about specific Cipher Suite used with TLS 1.2.
Regards, Max
5 years ago
Hi Max,
I set the server up with the following:
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
It is part of the recommendation found here:
https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html
I then relaxed this to the Turnkey VM default which is:
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256
5 years ago
Hi Cam,
I can confirm that none of the ciphers in the first list is enabled on our server, this is the reason why it did not work. This is operating system wide setting. Unfortunately there is no easy and safe method of changing it. So at this point we have to postpone the upgrade.
Regards, Max
5 years ago
Hi Max,
That makes sense and is what I would expect. No worries about the timeline on changing this as it is not critical.
In the long run, you may want to sync up with the current Apache recommendations as some organizations such as us will seek to have the most secure SSL connections in these days where corporate hacking is gaining big headlines.
Thanks for looking into this.