Certificate and Internet Requirements in K2

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

Using a Certificate

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

Keep in mind, however, that K2 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. K2 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 K2 (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:

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

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 K2 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.

InfoPath Forms services (legacy) does not support the use of client certificates.

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 K2 site.

K2 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 K2 server, you can install and use certificates from any location. However, K2 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}

K2 Cloud does not allow you to control where the certificates are installed as the K2 environment is provisioned by K2. 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 K2 Sites on the Internet

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