In this article we will show how to configure VMware vRealize Orchestrator (vRO) to use an SSL connection when communicating with a Microsoft SQL Server database.

• Introduction
• Lab Environment
• Enabling SSL on the SQL Server
• Trusting the SSL Certificate Chain on the vRO
• Enabling SSL for the vRO Databse Connection
• Final Step

 

Lab Environment

The logical design of this lab can be seen HERE.

 

Introduction

Microsoft SQL Server can use Secure Sockets Layer (SSL) to encrypt data that is transmitted across a network between an instance of SQL Server and a client application.
SSL can be used for server validation when a client connection requests encryption. If the instance of SQL

Server is running on a computer that has been assigned a certificate from a public certification authority, identity of the computer and the instance of SQL Server is vouched for by the chain of certificates that lead to the trusted root authority. Such server validation requires that the computer on which the client application is running be configured to trust the root authority of the certificate that is used by the server.  

The client application that will be configured with encrypted connection to the database In this article we be VMware vRealize Orchestrator (vRO). I wlll guide you how to configure vRO Appliance to use an SSL connection when communicating with a Microsoft SQL Server database.

 

Enabling SSL on the SQL Server

Before we can connect vRO to a SQL Server database using SSL, we need to configure the SQL Server to accept SSL connections.
Go to the SQL Server and start the SQL Server Configuration Manager

Navigate to SQL Server Network Configuration and select the database instance for which you want to configure SSL Communication.
Right click on Protocols for <Instance_name> and click Properties.
On the Flags tab, under Force Encryption select Yes.

On the Certificates tab, select the certificate you want to use for SSL communication and click OK

Trusting the SSL Certificate Chain on the vRO

The following screenshots show the certificate that was used in the previous step to force encryption in the SQL Server Configuration Manager.

As you can see the certificate is issued by a Certificate Authority (CA) called RootCA.

This is the certificate the server will present to any client application trying to establish a secure connection. The client application must be configured to trust the root authority of the certificate that is used by the server. In this example, the client application is vRO and the RootCA Certificate Authority certificate is the certificate that vRO must trust.

In order for vRO to trust the RootCA Certificate Authority certificate, we need to import it in the Trusted Certificates store in vRO.

Open vRO Control Center and navigate to Certificates, Trusted Certificates.
Import the RootCA Certificate Authority certificate.

In this example the CA Certificate chain consisted only of one CA, RootCA. If you have Intermediate CA, you should also import the Intermediate CA certificate into the Trusted Certificates store in vRO.

 

Enabling SSL for the vRO Databse Connection

Now let’s configure vRO to utilize encrypted connection to the database.

Open vRO Control Center and navigate to the Configure Database tab .
Fill in the Database information , select Use SSL, and click Save Changes.

Go to the Startup Options tab and restart the vRO Server Service.

We have not successfully configure vRO to utilize encrypted SSL connection to a Microsoft SQL Server database server.

 

Final Step

If all went well, go grab a beer.

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.