Tag Archives: SSL

How to create self-signed certificate for K2 NLB cluster add it to trusted root CA on client machines via GPO

I’ve recently recorded a video covering this topic, but I think it also makes sense to write a bit here, if only for giving you ability to copy paste related commands 🙂

When you install K2 blackpearl NLB cluster K2 Setup Manager can create K2 sites for you and it also creates HTTPS bindings for it. But K2 Setup Manager create individual self-signed certificates for each of the NLB cluster nodes which leads to ugly certificate security warning whenever you try to access K2 Workspace or any other K2 site.

To address this you have to do the following:

1) Create new self-signed certificate for your K2 NLB cluster name using New-Self signed certificate cmdlet:

New-SelfSignedCertificate -DnsName <server dns names> -CertStoreLocation cert:Localmachine\My

You have to do this on one of your K2 servers. This cmdlet will create new self-signed certificate and place it to Personal certificates store of your server. Copy certificate hash from output of this command – you will need it for next steps.

2) Next you want to obtain appid of your current K2 HTTPS app/binding using the following command (use elevated CMD for this):

netsh http show sslcert ipport=

Copy appid from the output to use it in step 3.

3) “Delete”/un-assign current SSL certificate from your HTTPS binding (one which was assigned by K2 Setup Manager):

netsh http delete sslcert ipport=

Insert your certificate thumbprint copied on step (1) and appid obtained on step (2) into the following command and execute it from elevated command prompt:

netsh http add sslcert ipport= certhash=<Cert thumbprint> appid={%YOUR  APP ID from step (1)%} certstorename=MY

At this point we created self-signed certificate and assigned it to HTTPS binding for K2 on our first server. But we still going to get certificate warning because our certificate is self-signed and not trusted. To address this it is necessary to import it into Trusted Root Certification Authorities on all machines which we will be using to access K2 sites.

4) At this step we will export certificate into P7B file to further import it into Trusted Root Certification Authorities. Execute the following in PowerShell:

$cert = Get-ChildItem –Path cert:\LocalMachine\My\<thumbprint>

Export-Certificate –Cert $cert –Filepath c:\servercert.p7b –Type P7B

This will create “servercert.p7b” file in the root of C drive. For testing purposed you can add it into Trusted Root Certification Authorities manually on your K2 server – right-click on it, select Install Certificate > Next >  Place all certificates in the following store > Browse > Trusted Root Certification Authorities > OK > Next > Finish.

At this point you should be able to access K2 Workspace via NLB name from your 1st K2 server assuming all above listed steps were performed on it and you not hit second node of your K2 NLB cluster by chance. To exclude the latter, you can take this node off-line or Stop in NLB Cluster Manager:

K2 NLB Stop Node

5) Now we can just deploy our P7B certificate file to Trusted Root Certification Authorities on all machines in our domain using GPO certificate deployment option (Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities):

K2 NLB Import Certificate GPO

Once you created this GPO and linked it to appropriate OU (one which contains machines from which you accessing K2 sites), you can update your local group policies on your client machines and access K2 sites via NLB name using HTTPS without any certificate related warnings.

6) Final touch 🙂 We need to add certificate created on step (1) to the second K2 server and configure it for use for K2 HTTPS binding on this second server. P7B file we created earlier does not fit for this purpose and we need export certificate once again including private key this time.

Run MMC on K2 server one and add Certificates snap-in targeting Computer Certificates store:

K2 NLB Open Computer Cert Store

Locate your K2 NLB cluster certificate created on step (1) and export it including private key:

K2 NLB Export Certificate

Make sure you select “Export Private Key”, specify password on certificate and in the end you should get PFX file. Copy this PFX file to your second server and install it to personal certificates store for this machine, then use IIS console and select this certificate to be used for K2 sites HTTPS binding.

That’s it – you created self-signed certificate for K2 NLB cluster name, configure it to be used on all your nodes and added it to the Trusted Root Certification Authorities on all your machines via GPO.

Here is the video which walk you through all these steps:


Configuring HTTPS for K2 SmartObject Services

There is a quite good section at help.k2.com which describes what you have to do in order to enable HTTPS for K2 SmartObject Services – “Windows Authentication with SSL for K2 SmartObject Services”. This post is sort of recap of that section with few extra bits of information.

So first you have to edit K2HostServer.exe.config file (default location – Program Files(x86)\K2 blackpearl\Host Server\Bin) as follows:

  1. Change enableEndpoints=”false” to enableEndpoints=”true”
  2. Change scheme=”http” to scheme=”https”
  3. Change port=”8888″ to port=”8443″
  4. Change wcf binding=“wsHttpBinding” bindingConfiguration= “wsHttpBinding+Windows” to wcf binding=“wsHttpBinding” bindingConfiguration= “wsHttpBinding+HTTPS”
  5. Change rest binding=“webHttpBinding” bindingConfiguration= “webHttpBinding+Windows” to rest binding=“webHttpBinding” bindingConfiguration= “webHttpBinding+Windows+HTTPS”
  6. Change excluded all=”true” to excluded all=”false”

As usual changes made to this config file will be picked up with K2 service restart, but it is better to done additional configuration task before restarting it – see next step.

  1. Configure the URL Access Control List so that the service account can use the https url by issuing following command:
netsh http add urlacl url=https://[server]:8443/ user=[domain\ServiceAccountUsername]
  1. Next you need configure the SSL for the port by issuing the following command:
netsh http add sslcert ipport= certhash=[CertificateThumbprint] appid='{4dc3e181-e14b-4a21-b022-59fc669b0914}'

Here some comments may be necessary. For certhash value you have specify value of CertificateThumbrint property of a certificate which is being used for HTTPS binding of your K2 site:

IIS Bindings View Certificate Properties 01

IIS Bindings View Certificate Properties 02

You need to copy Thumbprint value from certificate properties and specify it as a value of certhash property of aforementioned command (no spaces). As for appid property you may use GUID suggested in K2 help article {4dc3e181-e14b-4a21-b022-59fc669b0914} though according to some sources random GUID can be specified (you can use any valid GUID, as it is only used to allow you to identify the binding later).

So in the end command should look similar to this (if you run this in CMD window you don’t need to include appid value into single quotes but you do need this if you run the same in PowerShell window):

netsh http add sslcert ipport= certhash=e202039fac0b424d624d14b18102973cc7e7889c appid='{4dc3e181-e14b-4a21-b022-59fc669b0914}'

There is an alternative way to get your K2 site SSL certificate thumbrpint with use of PowerShell:

Write-Host (Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -match "K2.domain.com"}).Thumbprint;
  1. Once all that has been done you can restart K2 service and validate the results by accessing the following url (adjust URL accordingly):

If you see a page similar to one on the screenshot below then you successfully configured HTTPS for K2 SmartObject Services.

HTTPS endpoints.xml

Further reading/additional details: How to: Use basicHttpBinding with Windows Authentication and TransportCredentialOnly in WCF from Windows Forms