SoapUI in high DPI

Running SoapUI on my new fantastic 4K 15.6″ Windows 10 laptop had me looking for a pair of binoculars.

Windows 10 itself handles the extreme high DPI resolutions quite good. But SOAPUI does not scale very well. Luckily the solution is simple.


Add the following registry setting:

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide /v PreferExternalManifest /d 1 /t REG_DWORD

Create a file called {your-soapui-exe}.manifest in the SoapUI bin folder, such as soapUI-5.2.1.exe.manifest, with the following content:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?> <assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″ xmlns:asmv3=”urn:schemas-microsoft-com:asm.v3″> <description>soapui</description> <asmv3:application> <asmv3:windowsSettings xmlns=””> <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings=””>false</ms_windowsSettings:dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>


Done. Restart SoapUI and it scales so much better!

This could also be applied to other applications having the same problem.

Great times for cloud developers

The last couple of years has meant a incredible things for us developers as they now can stay focused on the important stuff and forget about stuff that used to take hours, days and sometimes even weeks.

Lets take an example. Using the Azure command-line tools (which are built in node/javascript and are platform agnostic running on Windows, Linux, OSX) and GIT i want to:

  • Create new cloudbased WebSite
  • Create a distributed source control repository locally and at my remote website
  • Setup automatic continuous-integration from the remote GIT repository
  • Create a html file
  • Add file to local repository
  • Push to remote repository and have the site automatically deployed from there.

Ok, lets begin…

azure site create reallycoolsite --location "North Europe" --git

copy con default.html
<!doctype html><title>Really cool site</title><p>Nothing to see here...</p>^z

git add .

git commit -m "Added deafult.html to this really cool site"

git push azure master

Thats it! Done! Thanks to Azure, Kudu and GIT it took 4 (!) commands. Well, 5 if you count creating the website homepage. The site could be ASP.NET, Node.JS, PHP or static HTML.

If this was an ASP.NET application i could attach to and debug the application running in Azure directly from my local Visual Studio.

Now what if we want to use the real power of cloud computing, scaling! Can we do that? Well then we need to issue another command…

azure site scale mode standard reallycoolsite

azure site scale instances 3 reallycoolsite

Now we have a website running load-balanced on 3 server instances. I can scale up and down and pay for the minutes i use. No IIS, no applicationppol, no NLB-setup and no script editing. The developer can focus on the site content and functionality.

When i need more control i just go to the default created log/debug/diagnostic site created by Kudu at https://<yoursite> Here you can copy files, look at deployment details and have a go at the shiny new debug console.

2014-02-02 09_45_16-Diagnostic Console


The abstraction and simplification provided by Azure Websites is really really effective and powerful yet lets you gain more detailed control when you need it.

SoapUI screen font problem

On my virtual (VMWARE) windows development machines i sometimes experience a very annoying visual problem in SoapUI where text and menu-items disappear as i move the mouse around. As seen below the File and Tools menu options are gone.

2013-10-17 09_05_21-Win7x64-BTS2010 - VMware Workstation

After poking around in the SoapUI settings without luck i finally tried the Windows Visual Effects settings in Windows 7 and after disabling the “Smooth edges of screen fonts” everything works just fine again. 🙂

2013-10-17 09_13_32-Win7x64-BTS2010 - VMware Workstation



SoapUI 2-way SSL problem using PKCS12

If you like me spend a lot of time in the swiss-army-knife of webservice development called SoapUI when not in Visual Studio or PowerPoint, you could end up getting bitten by this problem.


Java based SoapUI has great built-in support for both consuming webservices and exposing mockservices using 2-way SSL aka. two-way or mutual SSL. It is a proven and interoperable way to exchange data in B2B and enterprise scenarios in a secure way. It means that during the TLS/SSL handshake the client proves its identity to the server using a PKI challenge the same way as the server does to the client in normal TLS/SSL. To allow this the client needs a client certificate with a corresponding private key.


Doing most of my work in .NET i tend not to use the JKS (Java Key Store) that much and to call a webservice requiring certificate authentication in SoapUI i just point to a PKCS12 file directly. The PKCS12 file (.P12 or .PFX) are easy to move to and from the windows certificate store and is one of the standard containers for certificates with private keys.




Normally this works perfect but if you are having trouble getting the SSL handshake to work one (of many) reason can be that the client certificate you are using has a trust chain including an intermediate CA which is getting more and more common.
The symptom is that SoapUI during the handshake simply wont participate in the client authentication thus leaving you with either a 403 or simmilar.




In .NET this normally just works as you most likely have the complete chain of trusted certificate issuers in the Windows Certificate Store. But in SoapUI and other Java clients you can no longer rely just on the P12 file.


To solve this for SoapUI and other Java applications you need to create a JKS file containing the full certificate chain under the same alias.


1. Convert the PKCS12 to a JKS using Javas keytool.exe utility. You can find the utility in Javas JRE\BIN folder. If not elsewhere you have this together with the SoapUI installation.


jre\bin\keytool.exe -importkeystore -srckeystore MYCLIENTCERT.P12 -destkeystore MYCLIENTCERT.JKS -srcstoretype PKCS12 -deststoretype JKS -deststorepass password -srcstorepass password -destalias my-client-cert-alias -srcalias "my client cert"


2. Then you need all public certificates in the chain including both root and intermediate CA cert. Export them from windows certificate store in Base64 format (.CER)


3. Open all three files in a texteditor and chain them like this:
Save the file as my-complete-cert-chain.pem


4. Import the file to the JKS using
jre\bin\keytool.exe -import -keystore MYCLIENTCERT.JKS -alias my-client-cert-alias -file my-complete-cert-chain.pem


Now you got a JKS with your client certificate certificate chain that should work fine in SoapUI or in other Java-based webservice clients. 🙂