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=0.0.0.0:443
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=0.0.0.0:443
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=0.0.0.0:443 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:
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):
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:
Locate your K2 NLB cluster certificate created on step (1) and export it including private key:
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:
https://youtu.be/ePtP7GFngvo