Home > Blogs > VMware Consulting Blog > Tag Archives: Spas Kaloferov

Tag Archives: Spas Kaloferov

How to Add a Linux Machine as PowerShell Host in vRO

By Spas Kaloferov

Introduction

In this article we will look into the alpha version of Microsoft Windows PowerShell v6 for both Linux and Microsoft Windows. We will show how to execute PowerShell commands between Linux , Windows, and VMware vRealize Orchestrator (vRO):

  • Linux to Windows
  • Windows to Linux
  • Linux to Linux
  • vRO to Linux

We will also show how to add a Linux PowerShell (PSHost) in vRO.

Currently, the alpha version of PowerShell v6 does not support the PSCredential object, so we cannot use the Invoke-Command command to programmatically pass credentials and execute commands from vRO, through a Linux PSHost, to other Linux machines, or Windows machines. Conversely, we cannot execute from vRO –> through a Windows PSHost –> to Linux Machines.

To see how we used the Invoke-Command method to do this, see my blog Using CredSSP with the vCO PowerShell Plugin (SKKB1002).

In addition to not supporting the PSCredential object, the alpha version doesn’t support WinRM. WinRM is Microsoft’s implementation of the WS-Management protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that enables hardware and operating systems from different vendors to interoperate. Therefore, when adding a Linux machine as a PowerShell host in vRO, we will be using SSH instead of WinRM as the protocol of choice.

The PowerShell v6 RTM version is expected to support WinRM, so we will be able to add the Linux PSHost with WinRM, and not SSH.

So, let’s get started.

Continue reading

How to Change the Package Signing Certificate of a vRealize Orchestrator Appliance (7.0.1)

 

By Spas Kaloferov

In this post, we will take a look at how to change the Package Signing Certificate (PSC) in a vRealize Orchestrator appliance.

To change the PSC, let’s review a few steps first:

ŸIssue a certificate to meet the company’s requirements. The certificate must have:

  • ŸDigital Signature and Key Encipherment Key Usage attributes
  • ŸServer Authentication Extended Key Usage attribute
  • ŸAssurance that the certificate has a private key

ŸUse the keytool to:

  • ŸCreate new keystore; the keystore type must be JCEKS.
  • ŸImport the certificate into the keystore.
  • ŸChange the alias of the certificate to _dunesrsa_alias_.
  • ŸGenerate a Security Key and place it in the keystore.
  • ŸChange the alias of the Security Key to _dunessk_alias_.

ŸUse the Control Center interface to:

  • Ÿ Import the keystore you created.
  • Ÿ Restart the Orchestrator server.

Here is a screenshot of the original PSC certificate:

SKaloferov_PSC Certificate

Changing the Package Signing Certificate

First, you must obtain a PFX Certificate Package (containing your PSC Certificate) issued from the Certificate Authority (CA).

SKaloferov_Package Signing Certificate

SKaloferov_Package Signing Certificate 2

SKaloferov_Certificate Path

Note that the certificate has the Digital Signature and Key_Encipherment Key Usage attributes as shown above. It also has the Server Authentication Extended Key Usage attribute.

Copy the PFX certificate package to any Linux appliance.

SKaloferov_Certificate Signing vRO

Using the OpenSSL tool, enter the following commands to create a new keystore and import the PFX certificate package at the same time.

keytool -importkeystore -srckeystore "/etc/vco/app-server/security/rui.pfx" -srcstoretype pkcs12 -srcstorepass "dunesdunes" -deststoretype jceks -destkeystore "/etc/vco/app-server/security/psckeystore" -deststorepass "dunesdunes"

SKaloferov_PFX Certificate

Enter the following command to change the alias of the certificate:

keytool -changealias -alias rui -destalias _dunesrsa_alias_ -keystore "/etc/vco/app-server/security/psckeystore" -storetype jceks -storepass "dunesdunes"

Next, enter this command to generate a security key:

keytool -genseckey -alias _dunessk_alias_ -keyalg DES -keysize 56 -keypass "dunesdunes" -storetype jceks -keystore "/etc/vco/app-server/security/psckeystore" -storepass "dunesdunes"

Notice I’ve used the DES algorithm and 56 key size in the above command, but you can also use the 3DES (DESese) algorithm and 168 key size.

Enter the following command to list the contents of the store.

keytool -list -storetype jceks -keystore "/etc/vco/app-server/security/psckeystore"

Copy the keystore file to your Windows machine.

Open Control Center and navigate to Certificates > Package Signing Certificate.

Click Import > Import from JavaKeyStore file.

Browse the keystore file, and enter the password.

SKaloferov_Current Certificate

Click Import to import the certificate.

Go to Startup Options and restart the Orchestrator service.

Navigate back to Certificates > Package Signing Certificate.

You should now see the new certificate.

SKaloferov_New Certificate

Open your vRealize Orchestrator appliance client, and navigate to Tools > Certificate Manager.

SKaloferov_vRO

You should now see the certificate shown below. The common name can differ, but if you compare the thumbprints, it should match the private key entry in your keystore.

SKaloferov_Keystore

I hope this post was valuable in helping you learn how to change the Package Signing Certificate in a vRealize Orchestrator appliance. Stay tuned for my next post!


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Troubleshooting Tips: Orchestrator PowerShell Plug-in

By Spas Kaloferov

Background and General Considerations

In this post will we will take a look at some common issues one might experience when using the VMware vRealize Orchestrator (vRO) PowerShell Plug-In, especially when using HTTPS protocol or Kerberos authentication for the PowerShell Host (PSHost).

Most use cases require that the PowerShell script run with some kind of administrator-level permissions in the target system that vRO integrates with. Here are some of them:

  • Add, modify, or remove DNS records for virtual machines.
  • Register IP address for a virtual machine in an IP management system.
  • Create, modify, or remove a user account mailbox.
  • Execute remote PowerShell commands against multiple Microsoft Windows operating systems in the environment.
  • Run a PowerShell script (.ps1) file from within a PowerShell script file from vRO.
  • Access mapped network drives from vRO.
  • Interact with Windows operating systems that have User Access Control (UAC) enabled.
  • Execute PowerCLI commands.
  • Integrate with Azure.

When you add a PowerShell Host, you must specify a user account. That account will be used to execute all PowerShell scripts from vRO. In most use cases, like the one above, that account must be an administrator account in the corresponding target system the script interacts with. In most cases, this is a domain-level account.

In order to successfully add the PowerShell Host to that account—and use that account when executing scripts from vRO—some prerequisites need to be met. In addition, the use cases mentioned require the PowerShell Host to be prepared for credential delegation (AKA Credential Security Service Provider [CredSSP], double-hop authentication or multi-hop authentication).

To satisfy the above use cases for adding a PowerShell Host in vRO:

The high-level requirements are:

  • Port: 5986
  • PowerShell remote host type: WinRM
  • Transport protocol: HTTPS (recommended)
  • Authentication: Kerberos
  • User name: <Administrator_user_name>

The low-level requirements are:

  • PSHost: Configure WinRM and user token delegation
  • PSHost: Configure Windows service principal names (SPNs) for WinRM
  • PSHost: Import a CA signed-server certificate containing Client Authentication and Server authentication Exchange Key Usage Properties
  • PSHost: Configure Windows Credential Delegation using the Credential Security Service Provider (CredSSP) module
  • vRO: Edit the Kerberos Domain Realm (krb5.conf) on the vCO Appliance (Optional/Scenario specific)
  • vRO: Add the PS Host as HTTPS host with Kerberos authentication
  • vRO: Use the Invoke-Command cmdlet in your PowerShell code

Troubleshooting Issues when Adding a PSHost

To resolve most common issues when adding a PSHost for use with HTTPS transport protocol and Kerberos authentication, follow these steps:

  1. Prepare the Windows PSHost.

For more information on all the configurations needed on the PSHost, visit my blog, “Using CredSSP with the vCO PowerShell Plug-in.”

  1. After preparing the PSHost, test it to make sure it accepts the execution or removes PowerShell commands.

Start by testing simple commands. I like to use the $env:computername PowerShell command that returns the hostname of the PSHost. You can use the winrs command in Windows for the test. Here’s an example of the syntax:

winrs -r:https://lan1dc1.vmware.com:5986 -u:vmware\administrator -p:VMware1! powershell.exe $env:computername

 

Continue by testing a command that requires credential delegation. I like to use a simple command, like dir \\<Server_FQDN\<sharename>, that accesses a share residing on a computer other than the PSHost itself. Here’s an example of the syntax:

winrs -r:https://lan1dc1.vmware.com:5986 -ad -u:vmware\administrator -p:VMware1! powershell.exe dir \\lan1dm1.vmware.com\share


Note
: Make sure to specify the –ad command line switch.

  1. Prepare the vRO so it can handle Kerberos authentication. You need this in order to use a domain-level account when adding the PSHost.

For more information about the Kerberos configuration on vRO for single domain, visit my blog, “Using CredSSP with the vCO PowerShell Plugin.”

If you are planning to add multiple PSHosts and are using domain-level accounts for each PSHost that are from different domains (e.g., vmware.com and support.vmware.com) you need to take this into consideration when preparing vRO for Kerberos authentication.

For more information about the Kerberos configuration on vRO for multiple domains, visit my blog, “How to add PowerShell hosts from multiple domains with Kerberos authentication to the same vRO.”

If you make a mistake in the configuration, you might see the following error then adding the PSHost:

Cannot locate default realm (Dynamic Script Module name : addPowerShellHost#12
tem: ‘Add a PowerShell host/item8′, state: ‘failed’, business state: ‘Error’, exception: ‘InternalError: java.net.ConnectException: Connection refused (Workflow:Import a certificate from URL with certificate alias / Validate (item1)#5)’
workflow: ‘Add a PowerShell

 

If this is the case, go back and re-validate the configurations.

  1. If the error persists, make sure the conf file is correctly formatted.

For more information about common formatting mistakes, visit my blog, “Wrong encoding or formatting of Linux configuration files can cause problems in VMware Appliances.”

  1. Make sure you use the following parameters when adding the PSHost:
    • Port: 5986
    • PowerShell remote host type: WinRM
    • Transport protocol: HTTPS (recommended)
    • Authentication: Kerberos
    • User name: <Administrator_user_name>

Note: In order to add the PSHost, the user must be a local administrator on the PSHost.

  1. If you still cannot add the host, make sure your VMware appliance can authenticate successfully using Kerberos against the domains you’ve configured. To do this you can use the ldapsearch command and test Kerberos connectivity to the domain.

Here is an example of the syntax:

vco-a-01:/opt/vmware/bin # ldapsearch -h lan1dc1.vmware.com -D “CN=Administrator,CN=Users,DC=vmware,DC=com” -w VMware1! -b “” -s base “objectclass=*”
  1. If your authentication problems continue, most likely there is a general authentication problem that might not be directly connected to the vRO appliance, such as:
    • A network related issue
    • Blocked firewall ports
    • DNS resolution problems
    • Unresponsive domain controllers

Troubleshooting Issues when Executing Scripts

Once you’ve successfully added the PSHost, it’s time to test PowerShell execution from the vRO.

To resolve the most common issues when executing PowerShell scripts from vRO, follow these steps:

  1. While in vRO go to the Inventory tab and make sure you don’t see the word “unusable” in front of the PSHost name. If you do, remove the PSHost and add it to the vRO again.
  1. Use the Invoke an external script workflow that is shipped with vRO to test PowerShell execution commands. Again, start with a simple command, like $env:computername.

Then, process with a command that requires credential delegation. Again, as before, you can use a command like dir \\<Server_FQDN\<sharename>.

Note: This command doesn’t support credential delegation, so a slight workaround is needed to achieve this functionality. You need to wrap the command you want to execute around an Invoke-Command command.

For more information on how to achieve credential delegation from vRO, visit my blog, “Using CredSSP with the vCO PowerShell Plug-in.”

If you try to execute a command that requires credential delegation without using a workaround, you will receive an error similar to the following:

PowerShellInvocationError: Errors found while executing script <script>: Access is denied


SKaloferov_Power Shell Error

  1. Use the SilentlyContinue PowerShell error action preference to suppress output from “noisy” commands. Such commands are those that generate some kind of non-standard output, like:
    • Progress par showing the progress of the command execution
    • Hashes and other similar content

Finally, avoid using code in your commands or scripts that might generate popup messages, open other windows, or open other graphical user interfaces.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

How to Configure HA LDAP Server with the vRO Active Directory Plug-in Using F5 BIG-IP

By Spas Kaloferov

In this post we will demonstrate how to configure a highly availability (HA) LDAP server to use with the VMware vRealize Orchestrator Server (vRO) Active Directory Plug-in. We will accomplish this task using F5 BIG-IP, which can also be used to achieve LDAP load balancing.

The Problem

The Configure Active Directory Server workflow part of the vRO Active Directory Plug-in allows you to configure a single active directory (AD) host via IP or URL. For example:

SKaloferov_Configure Active Directory

Q: What if we want to connect to multiple AD domain controller (DC) servers to achieve high availability?
A: One way is to create additional DNS records for those servers with the same name, and use that name when running the workflow to add the AD server. DNS will return based on round robin, any of the given AD servers.

Q: Will this prevent me from hitting a DC server that is down or unreachable?
A: No, health checks are not performed to determine if a server is down.

Q: How can I implement a health checking mechanism to determine if a given active directory domain controller server is down, so that this is not returned to vRO?
A: By using F5 BIG-IP Virtual Server configured for LDAP request.

Q: How can I configure that in F5?
A: This is covered in the next chapter.

The Solution

We can configure an F5 BIG-IP device to listen for and satisfy LDAP requests in the same way we configured it for vIDM in an earlier post.

To learn more on how to configure F5 BIG-IP Virtual Server to listen for and satisfy LDAP requests, visit the “How to set vIDM (SSO) LDAP Site-Affinity for vRA“ blog, and read the Method 2: Using F5 BIG-IP chapter.

In this case we will use the same F5 BIG-IP Virtual Server (VS) we created for the vIDM server:

  1. Log in to vRO and navigate to the Workflows tab.
  2. Navigate to Library > Microsoft > Active Directory > Configuration and start the Configure Active Directory Server
  3. In the Active Directory Host IP/URL field provide the FQDN of the VS you created.
  4. Fill in the rest of the input parameters as per your AD requirements.
  5. Click Submit.

SKaloferov_Active Directory Server

Go to the Inventory tab; you should see that the LDAP server has been added, and you should be able to expand and explore the inventory objects coming from that plug-in.

SKaloferov_LDAP

Now, in my case, I have two LDAP servers lying behind the virtual server.

SKaloferov_F5 Standalone

I will shut the first one down and see if vRO will continue to work as expected.

SKaloferov_F5 Standalone Network Map

Right-click the LDAP server and select Reload.

SKaloferov_LDAP Reload

Expand again and explore the LDAP server inventory. Since there is still one LDAP server that can satisfy requests it should work.

Now let’s check to see what happens if we simulate a failure of all the LDAP servers.

SKaloferov_LDAP Pool

Right-click the LDAP server and select Reload.

You should see an error because there are no LDAP servers available to satisfy queries.

SKaloferov_Plugin Error

Additional resources

My dear friend Oliver Leach wrote a blog post on a similar/related topic. Make sure to check it out at: “vRealize Orchestrator – connecting to more than one domain using the Active Directory plugin.”


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Configuring NSX SSL VPN-Plus

Spas_KaloferovBy Spas Kaloferov

One of the worst things you can do is to buy a great product like VMware NSX Manager and not use its vast number of functionalities. If you are one of those people and want to “do better” then this article is for you. Will take a look how to configure SSL VPN-Plus functionality in VMware NSX. With SSL VPN-Plus, remote users can connect securely to private networks behind a NSX Edge gateway. By doing so remote users can access servers and applications in the private networks.

Consider a software development company that has made design decision and is planning to extend it’s existing network infrastructure and allow remote users access to some segments of it’s internal network. To accomplish this the company will be utilizing the already existing VMware NSX Manager network infrastructure platform to create a Virtual Private Network (VPN).

The company has identified the following requirements for their VPN implementation:

  • The VPN solution should utilize SSL certificate for communication encryption and be used with standard Web browser.
  • The VPN solution should use Windows Active Directory (AD) as identity source to authenticate users.
  • Only users within a given AD organizational unit (OU) should be granted access to the VPN.
  • Users should be utilizing User Principal Names (UPN’s) to authenticate to the VPN.
  • Only users who have accounts with specific characteristics, like those having an Employee ID associated with their account, should be able to authenticate to the VPN.

If you have followed one of my previous articles Managing VMware NSX Edge and Manager Certificates, you have already made the first step towards configuring SSL VPN-Plus.

Configuring SSL VPN-Plus is a straightforward process, but fine tuning it’s configuration to meet your needs might sometimes be a bit tricky. Especially when configuring Active Directory for authentication. We will look into a couple of examples how to use the Login Attribute Name and Search Filter parameters fine grain and filter the users who should be granted VPN access.

Edit Authentication Server tab on VMware NSX Edge:

SKaloferov Edit Authentication Server

Please visit Configuring NSX SSL VPN-Plus to learn more about the configuration.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC)

Spas_KaloferovBy Spas Kaloferov

The increasingly global nature of content and migration of multimedia content distribution from typical broadcast channels to the Internet make Geo-Location a requirement for enforcing access restrictions. It also provides the basis for traditional performance-enhancing and disaster recovery solutions.

Also of rising importance is cloud computing, which introduces new challenges to IT in terms of global load balancing configurations. Hybrid architectures that attempt to seamlessly use public and private cloud implementations for scalability, disaster recovery and availability purposes can leverage accurate Geo-Location data to enable a broader spectrum of functionality and options.

Geo-Location improves the performance and availability of your applications by intelligently directing users to the closest or best-performing server running that application, whether it be physical, virtual or in a cloud environment.

VMware vRealize Automation Center (vRA) will be one of the products in this Proof of Concept (PoC) for which use case(s) for Load balancing and geo-location traffic management will be presented. This PoC can be used as a test environment for any other product that supports F5 BIG-IP Local Traffic Manager (LTM) and F5 BIG-IP Global Traffic Manager (GTM). After completing this PoC you should have the lab environment needed and feel comfortable enough to be able to setup more advanced configurations on your own and according to your business needs and functional requirements.

One of the typical scenarios which involving Geo-Location based traffic management is the ability to achieve traffic redirection on the basis of the source of the DNS query.

Consider a software development company that is planning to implement vRealize Automation Center to provide private cloud access to its employees where they can develop and test their applications. Later in this article I sometimes refer to the globally available vRA private cloud application as GeoApp. Our GeoApp must provide access to the company’s private cloud infrastructure from multiple cities across the globe.

The company has data centers in two locations: Los Angeles (LA) and New York (NY). Each data center will host instance(s) of the GeoApp (vRealize Automation Center). Development (DEV) and Quality Engineering (QE) teams from both locations will access the GeoApp and use it to develop and test their homegrown software products.

Use Case 1

The company has made design decisions and is planning to implement the following to lay down the foundations for their private cloud infrastructure:

  • Deploy two GeoApp instances using vRealize Automation Center minimal setup in the LA data center for use by Los Angeles employees.
  • Deploy two GeoApp instances using vRealize Automation Center minimal setup in the NY data center for use by New York employees.

The company has identified the following requirements for their GeoApp implementation:

  • The GeoApp must be accessible to all the employees, regardless if they are in the Los Angeles or New York data center, under the single common URL geoapp.f5.vmware.com.
  • To ensure the employees get a responsive experience from the GeoApp (vRA) private cloud portal website, the company requires that LA employees be redirected to the Los Angeles data center and NY employees be redirected to New York data center.
  • The workload of the teams must be distributed across their dedicated local GeoApp (vRA) instances.

This is roughly represented by the diagram below:

SKaloferov vRA 1

  • In case of a failure of a GeoApp instance, the traffic should be load balanced between available instances in the local data center.

This is roughly represented by the diagram below:

SKaloferov vRA 2

Use Case 2 

The company has made design decision and is planning to implement the following to lay down the foundations for their private cloud infrastructure:

  • Deploy 1x GeoApp instance using VMware vRealize Automation Center (vRA) distributed setup in the Los Angeles  datacenter for use by the LA employees. In this case the GeoApp can be seen as a 3-Tier application, containing 2 GeoApp nodes in each tier.
  • Deploy 1x GeoApp instance using VMware vRealize Automation Center (vRA) distributed setup in the New York datacenter for use by the NY employees. In this case the GeoApp can be seen as a 3-Tier application, containing 2 GeoApp nodes in each tier.

The company has identified the following requirements for their GeoApp implementation:

  • The GeoApp must be accessible from all the employees, regardless if they are in the Los Angeles or the New York datacenter, under a single common URL geoapp-uc2.f5.vmware.com.
  • To ensure that the employees get a responsive experience from the GeoApp (vRA) private cloud portal website, the company requires that the Los Angeles employees be redirected to Los Angeles datacenter and the New York employees be redirected to New York datacenter.
  • The workload must be distributed across the Tier nodes of the local GeoApp (vRA) instance.

This is roughly represented by the diagram below:

SKaloferov vRA 3

  • In case of failure of a single Tier Node in a given GeoApp Tier, the workload should be forwarded to the remaining Tier Node in the local datacenter.

This is roughly represented by the diagram below:

SKaloferov vRA 4

  • In case of failure of all Tier Nodes in a given GerApp Tier , the workload of all tiers should be forwarded to the GeoApp instance in the remote datacenter

This is roughly represented by the diagram below:

SKaloferov vRA 5

Satisfying these requirements involves the implementation of two computing techniques:

  • Load balancing
  • Geo-Location-based traffic management

There are other software and hardware products that provide load balancing and/or Geo-Location capabilities, but we will be focusing on two of them to accomplish our goal:

  • For load balancing: F5 BIG-IP Local Traffic Manager (LTM)
  • For Geo-Location: F5 BIG-IP Global Traffic Manager (GTM)

Based on which deployment method you choose and what functional requirements you have you will then have to configure the following aspects of F5 BIG-IP devices, which will manage your traffic:

  • F5 BIG-IP LTM Pool
  • F5 BIG-IP LTM Pool Load Balancing Method
  • F5 BIG-IP LTM Virtual Servers
  • F5 BIG-IP GTM Pool
  • F5 BIG-IP GTM Pool Load Balancing Method (Preferred, Alternate, Fallback)
  • F5 BIG-IP GTM Wide IP Pool
  • F5 BIG-IP GTM Wide IP Pool Load Balancing Method
  • F5 BIG-IP GTM Distributed Applications Dependency Level

Implementing the above use case with GTM and LTM is roughly represented by the diagram below:

SKaloferov vRA 6

Implementing Use Case 2 (UC2) with GTM and LTM is roughly represented by the diagram below:

SKaloferov vRA 7

 To learn more about how to achieve the goal of Geo-Location Based Traffic Management using F5 BIG-IP Local Traffic manager (LTM) and F5 BIG-IP Global Traffic Manager (GTM) please visit Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC)


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.

Managing VMware NSX Edge and Manager Certificates

Spas_KaloferovBy Spas Kaloferov

di·ver·si·ty

“Diversity” was the first word that came to my mind when I joined VMware. I noticed the wide variety of different methods and processes utilized to replace certificates on the different VMware appliance products. For example, with VMware vRealizeTM OrchestratorTM, users must undergo a manual process to replace the certificate, but with VMware vRealizeTM AutomationTM administrators have a graphical user interface (GUI) option, and with VMware NSX ManagerTM there is another completely different GUI option to request and change for the certificate of the product.

 

Figure 1. SSL Certificates tab on the VMware NSX ManagerTM 

SSL Certificates tab on the VMware NSX Manager

This variety of certificate replacement methods and techniques is understandable as all of these VMware products are a result of different acquisitions. Although these products are great in their own unique ways, the lack of a common, smooth and user-friendly certificate replacement methodology has always filled the administrators and consultants with anxiety.

This anxiety often leads to certificate configuration issues among the majority of VMware family members, partners and end users. As a member of this family—and also of the majority—I recently felt this anxiety when I had to replace my VMware NSX Manager and NSX EdgeTM certificates.

pas·sion

I must say that up to the point where I had to replace these certificates, I had pretty awesome experiences installing and configuring VMware NSX Manager, and even developed advanced services like network load balancing. But I hit a minor roadblock with the certificates, and my passion to kick down any road block until it turns to dust wasn’t going to leave me alone.

ex·e·cu·tion

I got in touch with some of my awesome colleagues and NSX experts to get me back on the good experience track of NSX. As expected, they did (not that I have ever doubted them). Now, I was exploring the advanced VMware NSX Manager capabilities with full power – like SSL VPN-Plus where I had to again configure a certificate for my perimeter gateway edge device.

Figure 2. Server Settings tab of the SSL VPN-Plus setting on the VMware NSX EdgeTM

Server Settings tab of the SSL VPN-Plus setting on the VMware NSX Edge

This time I wasn’t anxious because I now had the certificate replacement process under control.

cus·to·mer

As our customers are core to our mission, we want to empower them by freeing them from certificate replacement challenges so they can spend their time and energy on more pressing technological issues. To help empower other passionate enthusiasts, and help keep them on the good experience track of NSX, I’ve decided to describe the certificate replacement processes I’ve been using and share them in a blog post to make them available to everyone.

com·mu·ni·ty

We are all connected. We approach each other with open minds and humble hearts. We serve by dedicating our time, talent, and energy – creating a thriving community together. Please visit Managing NSX Edge and Manager Certificates to learn more about the certificate replacement process.


Spas Kaloferov is an acting Solutions Architect member of Professional Services Engineering (PSE) for the Software-Defined Datacenter (SDDC) – a part of the Global Technical & Professional Solutions (GTPS) team. Prior to VMware, Kaloferov focused on cloud computing solutions.