Realex Payments recently announced that it will be ending support for TLS Version 1.0 and 1.1 and began sending emails out letting their customers know of this change.
I have written this guide which should help people use security best practices on an IIS Windows server, which should address the new Realex security requirements.
Please note that in order for the changes to take effect you will need to restart your server.
This guide is only for servers running Windows and IIS.
Your Web Applications (Web Sites) will also need to have an SSL Cert.
Step 1: Download IIS Crypto 2.0
Go to Nartac and download IISCrypto.exe to your server.
Step 2: Run IIS Crypto 2.0
Run the executable you just downloaded. It is a portable program so it doesn't install anything. The program should display a screen similar to the one shown here.
Step 3: Click the Best Practices Button
On the screen click the "Best Practices" button on the bottom left or select the options you want. The window should then look like the screen below. Once you are happy with the selected tick boxes. Click the "Apply" button.
Step 3: Restart your Server
After you clicked "Apply" you will need to reboot your server. IIS Crypto will tell you to do this (it will not reboot the server for you).
Step 4: Check your server at Qualys SSL Labs
Once your server and IIS has come back online you will need to check the rating of your server. Enter the URL of the site or the IP address of the server and have Qualys SSL test your server. You will want to get at least an A rating for server. If you do not get an A rating you will need to review your server's security settings and re-run the SSL Report.
I hope this helps anyone who may want to update their servers security.
Lately I learned of a new tool which gets and sets an SSL certificate automatically for you and renews itself every 3 months - Let's Encrypt.
I was eager to try out this new service on one of our Umbraco sites however, there was an issue when I tried to run the program.
Let's Encrypt adds a folder called ".well-known" to the root of the site. It then uses this folder to verify the site and issue an SSL certificate. When you attempt to do this using an Umbraco site you will be given an error which says something along the lines of "Let's Encrypt cannot access this folder".
In order to get the SSL issued and installed you will need to modify the WebConfig of your Umbraco site like below.
<add key="umbracoReservedPaths" value="~/umbraco,~/install/" />
<add key="umbracoReservedPaths" value="~/umbraco,~/install/,~/.well-known/" />
Re-run the Let's Encrypt program and the SSL certificate should then be issued and installed for your Umbraco site.
Note: That this will also work for Azure hosted Umbraco sites using the KUDU Let's Encrypt site extension.
I recently wrote how we submitted our first Octopus Deploy template to their online library for deploying .Net web apps to AWS Elastic Beanstalk using Octopus Deploy.
This time we needed to automate AWS Cloudfront cache invalidation. Turns out there are a few different ways to achieve this. You can either do it from the AWS console, by making a REST request or by using the AWS CLI tool.
Since authenticating against the AWS REST API is a bit more complex than we feel is necessary for the purpose of using it within an Octopus Deploy step, we decided to go with the AWS CLI approach (it's much easier to authenticate).
One more GitHub pull request and one more Octopus Deploy step template in their library in hope it might find someone in need. :)
The PowerShell script that does the hard work in the background of the template is the following (just fill in the AWS configuration variables):
$CredentialsProfileName = ""
$Region = ""
$DistributionId = ""
$AccessKey = ""
$SecretKey = ""
$InvalidationPaths = ""
Write-Host "Setting up AWS profile environment"
aws configure set aws_access_key_id $AccessKey --profile $CredentialsProfileName
aws configure set aws_secret_access_key $SecretKey --profile $CredentialsProfileName
aws configure set default.region $Region --profile $CredentialsProfileName
aws configure set preview.cloudfront true --profile $CredentialsProfileName
Write-Host "Initiating AWS cloudfront invalidation of the following paths:"
aws cloudfront create-invalidation --profile $CredentialsProfileName --distribution-id $DistributionId --paths $InvalidationPaths
Write-Host "Please note that it may take up to 15-20 minutes for AWS to complete the cloudfront cache invalidation"
The script uses profile setup for AWS credentials. If you don't want to use the profiles, you can just remove that bits from the script but then you might have to re-setup credentials for a different project every time.
Happy New Year! Here is a small 2017 present from Dovetail to everyone.
We normally use Azure to host the apps we make. The whole build and deploy with a single click process using TeamCity and Octopus Deploy is in place and it's trivial for us to add new projects to this pipeline.
Recently however, one of our clients wanted to host the .Net web app we're building for them on Amazon Web Services (AWS) because that's where the rest of their infrastructure is. Naturally not too many people host their .Net apps on AWS because MS Azure feels like a more natural fit. This meant it was a bit harder to find a fast and easy way to automate the deployment process to AWS through Octopus Deploy.
Anyway, we found this kind of half-baked solution (thanks!) on GitHub, made a few modifications, wrapped it up in a nice Octopus step template and made a pull request to Octopus library. :)
The template got accepted and can now be obtained from their library.
We hope it might help someone else and save them some time in setting the whole thing up.
Also, here are some more resources about deploying .Net apps to AWS which we found interesting.
codeproject.com - AWS deployment with octopus deploy
AWS docs - awsdeploy.exe tool
Octopus discussions - AWS elastic beanstalk
Octopus discussions - Modifying machines in environments to support AWS autoscaling
Octopus discussions - AWS beanstalk deployment using octopus deploy