A topic that has become even more relevant and very real of late is that of security.
From our perspective, as we transition to Accelerator5.0 and our new Outlook client, there is a new requirement for SSL. The change has generated some questions and so we will try to address them here.
Things are changing quickly in the area of security and whilst we are not security experts, we do have certain practices that we use and which may hopefully guide and advise you.
So firstly we will address the SSL (https) question.
In the last 2 years, browsers like Chrome/Firefox/Edge/Opera and Safari have all started showing a “Connection is not secure” message where https is not used.
“https” encodes your data in transit so that hackers cannot insert something in the middle to catch your data. That said, they might still be able to catch the data but will not be able to read it once https is in play, so data is of little use to any potential hacker.
All e-commerce sites use https as they are transmitting credit card details and security is obviously paramount. In our opinion, any and all of our data should be handled as securely.
Integrating with external API’s all require (or should all require) SSL.
One limitation since 2015 is the ability to get an SSL cert for an internal-only server. For example
“http://someserver/crm/….”
You can create self-signed certs but they will throw a warning up so they are no use really for production use. There are some ideas online about workarounds to use CA (Certificate Authority) certs on internal servers but it’s not something I would recommend (or we would support in our software).
One argument against having https on internal servers is: “…but it’s on my network and so it’s secure…”. Maybe it is secure but if it’s not then critical data can be intercepted as it flows through your network. Also, you would not be able to integrate with most modern API’s and systems. For example with Accelerator and the Office 365 API. Microsoft requires SSL and it will not work without it.
So what can you do?
Well, you need to assign an external IP to your server and using your DNS set up a route to your server. Then you can walk through the steps to create your cert. Usually, access to the domain is required for the authority to authenticate.
But you don’t want CRM accessible from the outside? We understand that and there are some options for this also. Once you get your cert you can do the following:
- Within IIS you can restrict access to certain IP addresses or IP address ranges.
You may need to add this option in via server manager.
See this Microsoft article for details on how to manage this
2. Using a VPN (we use OpenVPN but there are many out there)
A VPN (when connected) assigns an IP that is within the allowed range of a Windows firewall.
With this configuration, users could work from anywhere securely. With people needing to work from home or at least having the ability to, you can provide a modern adaptable workplace for your staff allowing better business continuity.
How to be extra careful…
We use 1Password to store internal and customer credentials. It’s great for generating complex passwords that are unlikely to be guessed and if you equip your users with this (or a tool like this…there are others on the market) and train them to use it for their VPN then it’s yet another layer of security to help protect you and your business.
How does https affect Sage CRM?
There are some points in the Sage CRM install guide.
If you select Use HTTPS for Sage CRM connections, you must manually add a server certificate on the web server (IIS) used by Sage CRM and create an HTTPS binding for the CRM site. For more information, see How To Set Up an HTTPS Service in IIS.
After you enable HTTPS, update the HTTPPort and OutlookPort entries in the Custom_Sysparams table in Sage CRM with the port you configured in the HTTPS binding settings.
As of writing the link below is the latest install guide that this is taken from
What about demo systems on laptops?
There are 2 options here. One is to create a self-signed cert. This can be problematic though and a better option IMO is to use a tool called “ngrok” (https://ngrok.com/) which generates a public URL to expose your localhost. Both these options should only be used on demo environments and not on live systems. Neither method is supported by CRM Together.
I hope you found this useful.
If you have any questions or comments please click on the Contact Us button below and send us a message.