Certificate and Internet Requirements

  • From Nintex Automation 5.7 onwards there are two different apps for SharePoint. The legacy Nintex K2 for SharePoint: used for SharePoint on-premises and upgraded environments for SharePoint Online, and Nintex Automation for SharePoint: used on new installations for SharePoint Online.

  • Existing customers upgrading to Nintex Automation 5.7 use the legacy app from the SharePoint App Catalog for all SharePoint environments. New installations of Nintex Automation use the legacy app from the SharePoint App Catalog for SharePoint on-premises, and the new Nintex Automation for SharePoint app (SPFx) for SharePoint Online.

Carefully read this section to determine where and when you need the product web sites and endpoints to be signed by a valid certificate and available on the internet.

Using a Certificate

We recommend using a certificate issued by a Certification Authority (CA) that is trusted by Windows, and that the same certificate is used for all web sites and endpoints.

Keep in mind, however, that the system generates and uses a self-signed certificate for web sites selected during installation that do not already have certificates.

Although you can use this self-signed certificate or a domain certificate, it is primarily for test scenarios. Nintex highly recommends using a certificate issued by a trusted CA to avoid both browser and remote event receiver certificate errors.

SharePoint Online requires that the certificate associated with SharePoint remote event receiver endpoint in Nintex Automation (https://{K2WebSite}/SP15EventService/RemoteEventService.svc) be issued by a CA that is trusted by Windows.

Errors associated with SharePoint Online remote event receivers, including invalid certificates, may take up to 24 hours to appear in the SharePoint Online logs (if at all).

You must be aware of your requirements when choosing an SSL certificate. For example, a single wildcard certificate for *.domain.com, works for the following domains:

  • runtime.domain.com
  • designer.domain.com
  • apps.domain.com

However, because the wildcard certificate only covers one level of sub-domains, the following domains are not valid for the *.domain.com certificate:

  • data.runtime.domain.com
  • forms.designer.domain.com
  • app-123356.apps.domain.com

To avoid false-negative SSL warnings such as ERR_CERT_COMMON-NAME_INVALID in distributed or load-balanced environments, you may need to configure your certificates with Subject Alternate Names or use wildcard certificates. The specific configuration and certificates needed will depend on your environment’s configuration. Consult with your network security specialists to determine which certificates will be necessary in your environment.

Two types of certificates exist - a server certificate and a client certificate. The purpose of the certificate is to identify that either the client or server making the service request is authorized to do so.

The issuing authority verifies the validity of the certificate when it issues it. When it expires is also determined by the issuing authority.

When are certificates required?

The server requires a certificate when it initiates a service request to one or more web service applications. The presence of the certificate is part of the service request transaction. It identifies both server and client machines as a source that can be trusted and authorized to make the service request, all verified by the signing authority. Certificates are used when initiating a process or submitting an item to a workflow. For example, when configuring a list or library to start a workflow when an item is added, the SharePoint call to the remote event receiver requires a server certificate for SharePoint Online.

Generating Certificates

An issuing authority, which can be internal to an organization, generates the certificate. Specialized software is used to generate the certificate, however this type of certificate is a self-signed certificate and although usable, browsers may report errors and block users from the product site.

The product supports Microsoft-based Certificate Services.

Installed Certificates

Once the certificate has been installed, it displays on the bottom of the internet browser when secure transactions are established. If it does not display, then the certificate has not been installed correctly and errors occur.

Storing Certificates

Certificates are installed locally on both server and client machines. Once the certificate has been issued, it is loaded onto the machine and retained in the local store. In some instances the client and server certificates are stored on their respective local machines, otherwise both server and client certificates are stored on the client machine.

Using Certificates

Certificate usage is dependent on how the environment has been configured. The server always stores the server certificate locally. The client machine may have either a client-only certificate, or both a client certificate and server certificate. These certificates are attached to the network communication and passed for identification purposes.

As you have control over your server, you can install and use certificates from any location. However, the product only offers support for the following scenarios:

Scenario 1
(recommended as it is the most common)		 Certificate Account: Local computer account
Certificate Store: Personal
Scenario 2 Certificate Account: Local computer account
Certificate Store: {something other than Personal}
Scenario 3 Certificate Account: User account
Certificate Store: Personal
Scenario 4 Certificate Account: User account
Certificate Store: {something other than Personal}

Nintex K2 Cloud does not allow you to control where the certificates are installed as the environment is provisioned by Nintex. The standard practice for installing certificates for use by a service is to use the following location:
Certificate Account: Local computer account
Certificate Store: Personal

The certificate cannot be exported.

SharePoint provides a similar feature to allow you to get your signing certificates installed on the SharePoint server. To do so, you can either use the IIS Manager or the SharePoint UI. In both cases, the certificate ends up in the location above.

See the following web page for more information: Microsoft SharePoint 2013: SSL Certificate Installation Instructions

Exposing Sites on the Internet

The web sites and SharePoint remote event receiver endpoints may need to be accessible on the internet depending on your scenario.

  • User Browser (Intranet Only): Web sites do not need to be internet-accessible when accessing those sites from within the company intranet or via VPN.
  • User Browser (Remote Access): Web sites do need to be internet-accessible when accessing these sites from outside the company intranet or VPN.
  • SharePoint Online Remote Event Receivers: The SharePoint remote event receiver endpoint in Nintex Automation (https://{K2WebSite}/SP15EventService/RemoteEventService.svc) must be internet-accessible when building event-based processes for SharePoint Online.