In this blog post we will take a look at how Digitally signing packages in VMware realize Orchestrator (vRO) may affect how you deploy vRO in your environment.
- Lab Environment
- Introduction
- Use Case 1 (Single Digital Signature Issuer)
- Use Case 2 (Multiple Digital Signature Issuers)
- Final Step
Update Log:
Lab Environment
The full lab logical design can be seen HERE.
Introduction
Digitally signing packages may affect how you deploy vRO in your environment.
Lets consider few examples.
Use Case 1 (Single Digital Signature Issuer)
Lets say you have vRO ServerA and vRO ServerB in your environment. You’ve performed the steps outlined in How to Change the Package Signing Certificate of a vRO Appliance (SKKB1029) article to change the PSC on vRO ServerA , export the keystore and import it on vRO ServerB. This will allow the following:
- vRO ServerA can digitally sign workflow packages and vRO ServerB can read packages digitally signed by vRO ServerA
- vRO ServerB can digitally sign workflow packages and vRO ServerA can read packages digitally signed by vRO ServerB (Vice-Versa)
Now what happens when you add vRO ServerC.
In addition to the above:
- vRO ServerC can digitally sign workflow packages and vRO ServerA and vRO ServerB can read packages digitally signed by vRO ServerC.
- vRO ServerA and vRO ServerB can digitally sign workflow packages and vRO ServerC read packages digitally signed by vRO ServerA and vRO ServerB.
This is great as long as you have imported the PSC keystore and the Private Key/Secret Key on all vRO Server. Let’s see what happens in a more complex scenario.
The following diagram illustrates the example:
Use Case 2 (Multiple Digital Signature Issuers)
Let’s say you have multiple customer’s digitally signing packages and you have to read the packages they send you.
Consider the following:
- CustomerA encrypts a package with PSC CertA from vRO ServerA and send you the package.
- CustomerB encrypts a package with PSC CertB from vRO ServerB and send you the package.
- Both customers can provide you their PSC Keystores (KeystoreA and KeystoreB) so that you can import them in vRO and read the digitally signed packages they send you.
- You have a single vRO ServerC Appliance .
Having in mind you have only one vRO appliance instance, in this use case, you will only be able to read packages from one Customer. This is because in order to read digitaly signed packages from both CustomerA and CustomerB you need to import both KeystoreA and KeystoreB keystores.
You cannot perform this on a single vRO appliance. A vRO appliance can only have one PSC Keystore. You will need to install a vRO appliance instance for each customer.
The following diagrams illustrated the example:
Now consider that CustomerA and CustomerB are actually vRA Tenants (TenantA and TenantB). If both tenands want to digitally sign packages and use their own PSC Certificates you may have to configure a different vRO Appliance instance for each vRA Tenant.
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.