Answers.Body: <p>This problem has been assigned to a CiviCRM bug which requires funding to resolve. The suggested fix is an AJAx solution.</p>
  
  <p>See:
  <a href="https://issues.civicrm.org/jira/browse/CRM-17663" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-17663</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-31T14:51:30.023Z
Answers.LastActivityDate: 2016-03-31T14:51:30.023Z
Answers.UserDisplayName: fred2
Body: <p>I've identified what may be bug or feature request, or at least a case of another item to add to the list of things which can make dashlets fail.</p>
  
  <p>I have an Apache 2.4 server which has multiple virtual hosts using different SSL certificates.</p>
  
  <p>Apache used not to support multiple SSL certs from different domains at all, but now it does it in effect because browsers specify which domain they want the SSL cert for. If a server has two certs installed "domainone.com" and "domaintwo.com" the user's browser needs to specify it wants to use the cert for "domaintwo.com", otherwise the server will provide whichever one comes earliest in the server config. This is apparently called Server Name Indication (SNI)(<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" rel="nofollow">https://en.wikipedia.org/wiki/Server_Name_Indication</a>)</p>
  
  <p>If using wget or cURL, SNI does not happen by default.</p>
  
  <p>Therefore, in my situation where I am using CiviCRM over an https connection, the dashlets will not load because they are loaded via cURL (I believe), and cURL will receive an error because it is using the wrong SSL certificate to connect.</p>
  
  <p>In theory this could be because of an old version of cURL installed on the server, but I have checked and that isn't the case.</p>
  
  <p>I believe it's more likely to be that the code needs to use something like SSL context options <code>SNI_enabled boolean</code> and <code>SNI_server_name</code> (<a href="http://php.net/manual/en/context.ssl.php" rel="nofollow">http://php.net/manual/en/context.ssl.php</a>), although I'm not sure how that integrates with using PHP's curl functions.</p>
  
  <p>As you can see, I haven't delved into the code to work out if this is all right.</p>
  
  <p>Could someone give me their thoughts on whether they agree this is the problem, and whether a code change would be beneficial?</p>
  
  <p>On a completely separate note - given that dashlets seem to be a persistent issue that can conflict with server configuration or minor user config file errors - wouldn't it be better to just rewrite them to use AJAX?</p>
  
Tags: <dashboard><dashlet><ssl>
Title: Dashlets and SSL in multiple secure virtualhost environment
ThreadText: # Dashlets and SSL in multiple secure virtualhost environment
  
  (Asked by: username_0 on 2016-03-15)
  
  I've identified what may be bug or feature request, or at least a case of another item to add to the list of things which can make dashlets fail.
  
  I have an Apache 2.4 server which has multiple virtual hosts using different SSL certificates.
  
  Apache used not to support multiple SSL certs from different domains at all, but now it does it in effect because browsers specify which domain they want the SSL cert for. If a server has two certs installed "domainone.com" and "domaintwo.com" the user's browser needs to specify it wants to use the cert for "domaintwo.com", otherwise the server will provide whichever one comes earliest in the server config. This is apparently called Server Name Indication (SNI)(<https://en.wikipedia.org/wiki/Server_Name_Indication>)
  
  If using wget or cURL, SNI does not happen by default.
  
  Therefore, in my situation where I am using CiviCRM over an https connection, the dashlets will not load because they are loaded via cURL (I believe), and cURL will receive an error because it is using the wrong SSL certificate to connect.
  
  In theory this could be because of an old version of cURL installed on the server, but I have checked and that isn't the case.
  
  I believe it's more likely to be that the code needs to use something like SSL context options `SNI_enabled boolean` and `SNI_server_name` (<http://php.net/manual/en/context.ssl.php>), although I'm not sure how that integrates with using PHP's curl functions.
  
  As you can see, I haven't delved into the code to work out if this is all right.
  
  Could someone give me their thoughts on whether they agree this is the problem, and whether a code change would be beneficial?
  
  On a completely separate note - given that dashlets seem to be a persistent issue that can conflict with server configuration or minor user config file errors - wouldn't it be better to just rewrite them to use AJAX?
  
  **Tags:** dashboard, dashlet, ssl
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-03-31. Score: 1 | Accepted answer
  
  This problem has been assigned to a CiviCRM bug which requires funding to resolve. The suggested fix is an AJAx solution.
  
  See:
  <https://issues.civicrm.org/jira/browse/CRM-17663>
  
  
  ---
  
  