Support shared SSL

[m.e.]

As nearly as I can tell (did I miss a success story?) .... civiContribute doesn't seem to happily co-exist with a server environment that uses shared SSL. Yet this is the most realistic setup for the non-profits who will benefit the greatest from an application as powerful as civiCRM.

I've installed and configured civiCRM within our Drupal test site only to learn that civiContribute donation pages probably aren't going to fly unless we leave our free Web hosting arrangement, buy an IP address, and have a certificate installed. What this means for our non-profit is, essentially, no civiCRM.

If this kind of support is something that could be incorporated in a later version, I'm sure it would be very favorably received. But lacking that, a lot of grief would be spared if the documentation were edited to be clearer about the problem of shared SSL (and by that I mean: just come out and say it probably won't work). When I chose civiCRM it was because our merchant account is supported, and because I thought the language about "secure server" included accessing our Web host's certificate. The "?" popup in the admin > global settings > resource URLs > force secure URLs (SSL) field explains exactly how to test whether SSL is available, and we pass that test -- I can open our sample contribution page on our Web host's https. Yet I still get an error message ("you need to set up a secure server...") upon choosing the force secure URLs (SSL) option, and the donation page that opens does so without a stylesheet (lost somewhere in the maze of server root running virtual root running Drupal running civiCRM and on down the line).  There are probably developers with more time and skill than I who could sort all this out; I have to rely on my Web host and the support boards here, which have so far had no answers for me. 

So if, as I suspect, it's established that shared SSL doesn't work in civiContribute, please at least let that limitation be reflected in the docs, help files, and promotional language, if it is too complex a problem to solve in the next release.

Thanks in any case for a great piece of software which I only hope we can find a way to keep. 

[Donald Lobo]

the wiki and documentation are editable by the community. Please feel free to edit them to make it more clear that CiviCRM does not support shared SSL

shared SSL support is not on the current roadmap.

lobo

[m.e.]

Ok, I will do that, if you're saying it is definitely the case that shared SSL cannot be made to work. I have seen several posts by people attempting ... I haven't seen anyone cry Eureka, but that doesn't mean they haven't done so privately and forgotten to tell us.

The part I cannot change is the pop-up on the interface that turns on/off forcing of secure URLs.

[Donald Lobo]

We've not heard of anyone getting it to work with shared SSL either, so i suspect not.

We'll take care of the help text on the pop-up

lobo

[Eileen]

Hi,

I'm sure you realise this but I would note to anyone else reading this that if you wish to accept credit card payments but do not have a suitable ssl certificate you should focus on a payment processor that processes the credit card transactions off-site (usually called a hosted payments page)

For most people this means my least favourite processor - Paypal.

Others include

• Payment Express (which is mostly NZ / Aust / Pacific but has a smattering of South Africa, UK & US.) Not a good low volume option though.
• Google Checkout from the looks of it?
• Paymex - NZ only
• Sogenactif - soon - Eurocentric

[m.e.]

Currently we process donations that way both on PayPal and Authorize.Net. Presumably PayPal integration will be straightforward. However, civiCRM does not support the usage of Authorize.Net that avoids the need for SSL on one's own domain (the "SIM" method, which we use currently).  I know you are well aware of all this! -- I'm posting it here for anyone that might have missed it in other places.

When I have a moment I will attempt to update the documentation to make the SSL requirements clearer. I feel something should also be added to the Technical Requirements on this page: http://civicrm.org/aboutcivicrm - even though it is not a universal requirement.

[CMLA]

As you have likely figured out, a shared SSL will not work - we were in the same boat.

Our hosting provider had an option to upgrade to a business package (with a static IP and 1 SSL) for only 2 dollars more a month. Check into that.

[Eileen]

People are probably wondering who your posting provider is around about now

[m.e.]

We're evaluating our options, yes. The issue here is not so much money; it's hassle. I am currently hosting this non-profit pro bono on my private server account. I can purchase an IP and certificate, but even if I do so, it'd be on the primary domain (mine), not the non-profit's. So we'd still be stuck with shared SSL - a little less shared, but still not good enough for CiviCRM. Another option is to move the site to its own account somewhere where it would be the primary domain. We've moved 2x already in the past year (long story) and I'd kinda like to avoid another migration .... If we're willing to forego CiviCRM altogether I can create a donation page on a subdomain outside Drupal -- keep our donation system the same as it is now, essentially (collecting card info on the merchant account's site, not ours). I had hoped to give staff the benefits of CiviCRM, though, as long as we're reinventing ourselves within Drupal.

[EdP]

We use a payment processor (SagePay, was Protx). We have commercial hosting, but shared SSL - dedicated SSL would be expensive for us. Currently we collect payments via Joomla and Virtumart, plus some code to link to SagePay.

How can we do this in CiviCRM? Does the lack of shared SSL mean that we can't do it, or is it just that I haven't found any code for connecting to SagePay (who take all the credit card details on their site etc) - or do I not even need that?

Sorry, but I have found this confusing and as the original poster says, if we can't use shared SSL and had to pay for individual SSl that would double our hosting costs for the year (near as).

EdP

[Dave Greenberg]

If SagePay collects the credit card info on their site, then you can potentially do without SSL. However, as far as I know there is no CiviCRM  payment processor plugin for SagePay. There are a number of plugins for other processors:

http://wiki.civicrm.org/confluence/display/CRMDOC/CiviContribute+Payment+Processor+Configuration

... and the possibility of you / your organization developing and contributing a plugin for SagePay (many of the existing plugins where contributed by community members).

[EdP]

Thanks.

I'm always very impressed with the prompt and helpful answers I get on these forums, by the way...

[EdP]

I have found this:
http://anarres.ca/blog/derek/civicrm-protx-payment-processor-alpha
which appears to be an attempt at a payment processor for protx, at least. Haven't got it to work yet, though!

[Eileen]

Hi there,

I took a look at the blog. The code is for v1.9 - that may not be a problem but one thing I spotted.

The tarball contains files to go in

CRM/Core/Payment/ProtX.php
CRM/Contribute/Payment/ProtX.php
packages/Services/ProtX/includes.php

For event payments you will also need a file
CRM/Event/Payment/ProtX.php

If you take a look at the files already in that location you should be able to create that file quite easily - it's a very straight forward file