mTLS

The public internet uses One-way TLS.

TLS, which was formerly called SSL, serves three purposes:

• To ensure that people visit a trusted website
• To encrypt communications between client and server so that external parties cannot spy on the communications
• To make sure that data is not altered in transit.

The server encrypts all traffic with its private key. The client decrypts all traffic with the public key. Anyone can view the public key, the certificate authority (who issued the certificate) and the expiration date. Note that distributing billions of TLS certificates (X.509) to all clients on the public internet is an impossible task. That’s the reason that the client simply trusts all certificates that are issued by a limited number of certificate authorities (making use of the certificate chain). The public key of the server certificate doesn’t need to be distributed with TLS. 

The typical TLS process works like this:

1. Client connects to server
2. Server presents its TLS certificate
3. Client verifies the server’s certificate
4. Client and server exchange information over encrypted TLS connection

On a smaller scale, in business-to-business scenarios, mutual TLS (or mTLS) is highly useful. TLS ensures that the parties at each end of a network connection are who they claim to be. It ensures traffic is secure and trusted in both directions between a client and server. mTLS is often used in a Zero Trust security framework.

mTLS works like this:

1. Client connects to server
2. Server presents its TLS certificate
3. Client verifies the server’s certificate
4. Client presents its TLS certificate *
5. Server verifies the client’s certificate *
6. Server grants access *
7. Client and server exchange information over encrypted TLS connection

The organization implementing mTLS acts as its own certificate authority. This contrasts with standard TLS, in which the certificate authority is an external organization that checks if the certificate owner legitimately owns the associated domain. To be it’s own certificate authority, a self-signed root certificate is necessary. Self-signed means the organization creates the certificate themselves. The certificates used by authorized clients and servers have to correspond to the organization’s root certificate.

BTDF Determine Environment

To identify the deployment environment in BizTalk Deployment Framework scripts, you use an environment variable by default. You can also use a RSA certificate however. To this end you will have to create a BTDF extension. In this post, I will not show the extension code. This post is just aims to make you aware of the possibility a certificate is used. Gotchas:

• Self signed RSA certificates can easily be generated via IIS. Use a certificate that doesn’t expire and make a backup. The certificate must be added to the personal certificate store of the computer account.
• The deployment environment can only be determined if a setting PasswordEncryptionPublicKey is added to the BTDF settings file. PasswordEncryptionPublicKey contains the base64 encoded public key. You create a certificate per environment.
• As mentioned before, a RSA certificate can be used to determine the environment. As an added advantage you can also use certificates to decrypt sensitive information from the settings file. To decrypt sensitive information add ‘__’ in front of the setting name. Example: ‘Password’ will be ‘__Password’. On the next deployment, the field will be encrypted using the public key.
• To view the installed certificate, enter Start/Run mmc en Add the Certificates add-in.

BTDF Extensions are added to path:

C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0

As an example, task DetermineCurrentEnvironment.cs is contained in a library named BtdfExtensions.Tasks.dll. In the Deployment file Deployment.btdfproj of solution BtdfExtensions, you will see the other Extension artefacts are also added to folder C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0.
Example:

<Copy DestinationFolder="$(MSBuildProgramFiles32)\MSBuild\DeploymentFrameworkForBizTalk\5.0\" SourceFiles="@(TargetsToCopy)"/>

Note that $(MSBuildProgramFiles32) is a reserved property of MSBuild, that contains value C:\Program Files (x86)\MSBuild. The extensions include scripts, tasks, targets and xslt’s.

Using Certificates in Azure

For a recent RFI I had to call a SOAP webservice using a X.509 certificate. This made me look into the issue of using certificates. Obviously you don’t have a certificate store in Azure. So, how does it work?

First all, I found out that things work differently for cloud services (web+worker roles) and Azure Websites. In Azure Cloud Services you can simply upload a certificate through the Azure Management Portal. Next you can specify that certificate’s thumbprint and install location in your role’s properties. On deployment, the fabric controller automatically installs the certificate for you. That makes sense, because each role gets deployed into a virtual machine (with a certificate store I guess). The following code loads the uploaded certificate:

private List GetAvailableCertificatesFromStore()
{
var list = new List();
var store = new X509Store(StoreName.My,StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadOnly);

try
{
foreach (var cert in store.Certificates)
{
// todo: add friendly name
list.Add(string.Format(“{0}”, cert.Subject));
}
}
finally
{
store.Close();
}

return list;
}

In the Azure Website scenario things work a little differently. Because of security restrictions in an Azure website, you just can’t install a certificate in the certificate store. To work with certificates, you would need to include the certificate’s PFX file in the AppData folder. Still you may run into errors like “CryptographicException: The system cannot find the file specified. Check the following blog post: http://blog.tylerdoerksen.com/2013/08/23/pfx-certificate-files-and-windows-azure-websites/.

Later on in the original blog post, I read an alternative way to work with certificates. Not sure which version is the correct one. Working procedure:

• Upload your certificate through the Azure Portal.
• Add an appsetting called WEBSITE_LOAD_CERTIFICATES and set its value to the thumbprint of the uploaded certificate (use a comma separated list for multiple thumbprints, or use the * wildcard to load all your uploaded certificates). I’m presuming this forces the certificates to be loaded in to memory.
• To load your certificate, you can do the following:

var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
var certs = store.Certificates.Find(X509FindType.FindByThumbprint, YOUR_THUMBPRINT, false);

Change the ‘false’ to ‘true’ if you want to ensure the certificate is valid. I found this information here, which explains it much better than I have: http://azure.microsoft.com/blog/2014/10/27/using-certificates-in-azure-websites-applications/

Additional reading:
Link 1: Signing a SOAP message using a certificate (non Azure)
Link 2: Export certificate + Add to Azure Portal (old?)

Creating a https webservice

Om een http webservice te creeëren, heb je eerst een self signed certificate nodig. Run Visual Studio Command Prompt as an administrator en voer de volgende commando’s uit:

//Create self-signed certificate for the root authority
makecert -n “CN=Erpobizzw004CA” -r -sv Erpobizzw004CA.pvk Erpobizzw004CA.cer -sky exchange
//Als er gevraagd wordt om een password, typ dan bijvoorbeeld password: biztalk

//Add certicate to Trusted Root Certifcate Authority store
certmgr -add Erpobizzw004CA.cer -s -r localmachine root
//This tool also opens the mmc, but you also perform the steps manually:

// Start/Run mmc
// Add snap-in Certificates, choose Computer Account
//Expand node Trusted Root Certifcate Authority store in the MMC
//Right-click Certificates
//Import, select Erpobizzw004CA.cer

//Install in personal store
makecert -sky exchange -sk localhost -iv Erpobizzw004CA.pvk -n “CN=localhost” -ic Erpobizzw004CA.cer localhost.cer -sr localmachine -ss My
//enter password: biztalk

Nadat je het self-signed certificate hebt, kun je in IIS een nieuwe website creeëren naast de default website. Noem de website bijvoorbeeld SecureWebSite en gebruik als filepad C:\inetpub\wwwrootsecure. Vervolgens kun je aan de nieuwe
Voor een toelichting, zie de volgende link: http://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis

• Right-click de website en kies Edit Bindings. Voeg een binding toe voor https, port 443 en selecteer het aangemaakte self-signed certificate.
• De tweede stap. Configure SSL settings is niet nodig. Volgens mij gebruik je deze stap alleen als je een certificate wilt gebruiken als client credential.

Let op. Als je nu je applicatie installeert onder de nieuwe website, dan moet je een service behavior httpsGetEnabled toevoegen i.p.v. httpGetEnabled.

<serviceBehaviors>
<behavior name =”RESTServiceBehavior”>
<serviceMetadata httpsGetEnabled=”true”/>
<serviceDebug includeExceptionDetailInFaults=”true”/>
</behavior>
</serviceBehaviors>

Zorg ook dat de website gestart is. Noot: Niet alleen de webserver moet gestart zijn, maar ook de websites. Voor een check. Right-click de website en kies voor Manage Website. Je kunt nu de website starten of stoppen.

Voor de test, kun je nu in Content view de svc file selecteren en kiezen voor browse. Vervolgens wordt de service file geopend via https en zie je een wsdl pagina.