The procedure to replace SSL certificates
has changed in recently released VMware View 5.1 and differs from 5.0 or
earlier versions. The main difference is that native Windows
certificate store is used. Also it is now necessary to replace or at
least to verify self signed certificates otherwise the View
infrastructure will not work properly.
Which servers need to replace the certificates? View Connection
Managers, Security servers and View Composer. Also vCenter certificate
must be replaced or validated.
Although the certificate replacement procedure is described in the
manual, the description is very brief and it took me some time to figure
it out. I also found an existing blog post which takes different angle
My lab configuration is following. View
Composer is installed together with vCenter. I have two View Connection
Managers; one for internal connections and one for external internet
connections. I do not use Security server as I use port forwarding to
the external View Connection Manager. All servers are in the domain with
Enterprise CA which uses self signed certificate.
View Composer Certificate
My View Composer server is coexisting with
vCenter so I did not need to generate new certificate. I just imported
the vCenter certificate from C:\ProgramData\VMware\VMware
VirtualCenter\SSL into the local Windows certificate (Personal) store
via MMC Certificates Snap-in.
Select the .pfx file which contains both private key and the certificate.
Now we have to stop the View Composer process and run SviConfig command to replace the certificate:
C:\Program Files (x86)\VMware\VMware View Composer>SviConfig.exe -operation=replacecertificate -delete=false
and select the new certificate.
Start the View Composer process again and check the status in the View Administrator.
View Connection Servers
Here we have to generate the certificates.
To do this I am again using the Certificates Snap-in. However prior to
that I needed to give both of my Connection Server access to Web Server
On my CA open the Certificate Templates Management Console Snap-in and open properties of Web Server certificate template.
Open the security tab and add both View Connection computers and give them read, write and enroll permissions.
Now we can go to each Connection Server Certificates Snap-in and right click, select All Tasks and Request New Certificate.
Select Active Directory Enrollment Policy and Web Server certificate template.
Now we have to add FQDN and additional info to the certificate. Click the More information is required … link.
Type in the Common name (FQDN), Country, Locality, Organization and any
other info that will be visible inside the certificate. If your
Connection server uses different internal (viewcs2.fojta.com) and public (public.url.com) Fully Qualified Domain Names add both and do the same for the Type: DNS field. The end result should look like this:
And do not forget to make private key exportable in the Private Key tab / Key options.
Click enroll and finish.
Now we should see the newly created certificate. Last thing we need to
do is to change the certificate Friendly Name to vdm. This can be done
in the certificate properties. Also we have to rename the original
Once this is done we can restart the View services.
Repeat for all other View Connection servers and check the result in the View Administrator.
As I said at the beginning my CA uses self signed certificate so I have to make sure all the non-domain PCs I use to connect to my View desktops imported the CA Root certificate into the Trusted Root Certification Authorities store.
1) Determine the domain controller that holds the Domain Naming Master
Flexible Single Master Operations (FSMO) role. To identify the server
holding this role: 1.1) Start the Active Directory Domains
and Trusts Microsoft Management Console (MMC) snap-in from the
Administrative Tools menu. 1.2) Right-click the root node in
the left pane titled Active Directory Domains and Trusts, and then click
Operations Master. 1.3) The domain controller that currently
holds this role is identified in the Current Operations Master
frame.NOTE: If this changed recently, not all computer may have received
this change yet due to replication. For more information
about FSMO roles, click the following article number to view the article
in the Microsoft Knowledge Base:
2) Verify that all servers for the domain have been demoted. 3) Click Start, point to Programs, point to Accessories, and then click Command Prompt. At the command prompt, type: ntdsutil. Type: metadata cleanup, and then press ENTER.
Type: connections, and then press ENTER. This menu is used to
connect to the specific server on which the changes will occur. If the
currently logged-on user is not a member of the Enterprise Admins group,
alternate credentials can be supplied by specifying the credentials to
use before making the connection. To do so, type: set creds domainname
username password , and then press ENTER. For a null password, type:
null for the password parameter. Type: connect to server
servername (where servername is the name of the domain controller
holding the Domain Naming Master FSMO Role), and then press ENTER. You
should receive confirmation that the connection is successfully
established. If an error occurs, verify that the domain controller being
used in the connection is available and that the credentials you
supplied have administrative permissions on the server. Type: quit, and then press ENTER. The Metadata Cleanup menu is displayed. Type: select operation target, and then press ENTER. Type: list domains, and then press ENTER. A list of domains in the forest is displayed, each with an associated number. Type: select domain number, and then press ENTER, where number is the number associated with the domain to be removed. Type: quit, and then press ENTER. The Metadata Cleanup menu is displayed.
Type: remove selected domain, and then press ENTER. You should
receive confirmation that the removal was successful. If an error
occurs, please refer to the Microsoft Knowledge Base for articles on
specific error messages. Type: quit at each menu to quit the
NTDSUTIL tool. You should receive confirmation that the connection
disconnected successfully. see ref
IF it gives the error: “DsRemoveDsDomainW
error 0x2162(The requested domain could not be deleted because there
exist domain controllers that still host this domain.”
THEN do the following
1) open mmc
2) go to add / remove snap-in and select ADSI-Edit & click ok
3) Right Click on ADSI-Edit and select “Configuration” under select a well known Naming Context. Click ok to exit
4)Under CN=Sites delete the child domain controllers from the respective site(s)
This should clear up the above error.
run the above step again – it should be able to complete sucessfully. IF you get this error “DsRemoveDsDomainW error 0x2015(The directory service can perform the requested operation only on a leaf object”
Use the following steps to get rid of the error.
1) Click Start, click Run, type ntdsutil, and then press ENTER. At the Ntdsutil command prompt, type partition management, and then press ENTER. 2) Type connections, and then press ENTER. 3) Type connect to serverDomain_Controller_Name, and then press ENTER. After the following message appears,“Connected to Domain_Controller_Name using credentials of locally logged on user” type quit, and then press ENTER: 4) At the domain management prompt, type list, and then press ENTER. Note the following entry: DC=DomainDnsZones,DC=Child_Domain, DC=extension For example, if the child domain is let.do.com, note the following entry: DC=DomainDnsZones,DC=let,DC=do,DC=com Type the following command, and then press ENTER. delete nc dc=domaindnszones,dc=Child_Domain,dc=extension Note In this command, Child_Domain represents the name of the child domain that you want to remove. For example, if the child domain is let.do.com, type the following command, and then press ENTER: delete nc DC=DomainDnsZones,DC=let,DC=do,DC=com Quit Ntdsutil.
see ref Once this is removed, then you can again remove the child domain using ntdsutil from the top.
Launch the VMware vSphere 6.x Certificate Manager:
vCenter Server 6.x Appliance: /usr/lib/vmware-vmca/bin/certificate-manager
Windows vCenter Server 6.x: C:\Program Files\VMware\vCenter Server\vmcad\certificate-manager Note: It is important to be logged in as an administrator or to “Run as Administrator” if user access control is enabled.
Select Option 1 (Replace Machine SSL certificate with Custom Certificate).
Provide the firstname.lastname@example.org password when prompted.
Select Option 1 (Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate).
Enter the directory in which you want to save the certificate signing request and the private key.
Refer to the below information to enter values for CSR generation.
Country : Two uppercase letters only (Eg. US), the country where your company is located. Name : FQDN of the vCenter Server(This will be your Certificate Subject Alternate Name) Organization : Company Name OrgUnit : The name of your department within the organization. Example: “IT” State : The state/province where your company is located Locality : The city where your company is located. IPAddress : IP Address of vCenter Server, this field is Optional Email : Email Address Hostname : FQDN of vCenter Server(This field accepts multiple entries separated by comma.
For example: VCSA1.vsphere.local,vcsa1,192.168.0.51) VMCA Name : FQDN of vCenter Server with VMCA (Usually External PSC or VC with Embedded PSC FQDN)
Note: make sure the Primary Network Identifier (PNID) matches the Hostname
To obtain the PNID please refer to the following commands for appliance and windows respectively:
Provide the full path to machine_name_ssl.cer and vmca_issued_key.key from Step 5 and the CA certificate Root64.cer.
Note: If you have one or more intermediate certificate authorities, the root64.cer should be a chain of all intermediate CA and Root CA certificates. The “machine_name_ssl.cer” should be a full chain for certificate+inter(s)+root.
The machine_name_ssl.cer should be a complete chain file similar to:
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <—–Intermediate Certificate
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <—–Root Certificate
vCenter Server Appliance:
Provide a valid custom certificate for Machine SSL.
File : /tmp/ssl/machine_name_ssl.cer
Provide a valid custom key for Machine SSL.
File : /tmp/ssl/machine_name_ssl.key
Provide the signing certificate of the Machine SSL certificate.
File : /tmp/ssl/Root64.cer
Windows vCenter Server:
Provide a valid custom certificate for Machine SSL. File : C:\ssl\machine_name_ssl.cer
Provide a valid custom key for Machine SSL. File : C:\ssl\machine_name_ssl.key
Provide the signing certificate of the Machine SSL certificate. File : C:\ssl\Root64.cer
Answer Yes (Y) to the confirmation request to proceed.
When Certificate Manager prompts for the certificate, Enter the
proper value for VMCA Name enter the Root Cert Name (That is Issuer Cert
CA Common Name).
This task replaces the Machine SSL Certificate with a Custom CA Signed Certificate.
This certificate is not issued by VMCA. It is issued by an external Certificate Authority.
If you are running an external Platform Services Controller (deprecated in 6.7.x),
you will need to restart the services on the external vCenter Server
6.x and then proceed with replacing the Machine SSL of the vCenter
Yes, it’s possible to have a (virtual) MikroTik router in the cloud.
provide a version of RouterOS which supports the x86-64-bit
architecture and can be used on most of the popular hypervisors such as
VMWare, Hyper-V, VirtualBox, KVM and others. This version name is MikroTik CHR, (Cloud Hosted Router).
default in the MS Azure marketplace there are no MikroTik appliance
templates, but you can create custom OS images to deploy a virtual
Create an OS image from the uploaded image: (CHR image only supports Hyper-V generation 1, ‘V1’ virtual machines)
az image create --name chr646image --resource-group DemoRSC --location northeurope --os-type linux --hyper-v-generation V1 --source https://chrteststorageaccount.blob.core.windows.net/imagecontainer/chr-6.46.7.vhd
Finally deploy a VM from the image: (select a cheap vm size, Standard_B1ls is more than enough and it’s only 4EUR / month)
az vm create --name CHRVM --resource-group DemoRSC --location northeurope --size Standard_B1ls --image chr646image --admin-username username --admin-password Apple123456789@ --nsg-rule SSH
Get the VM’s public IP address and connect via SSH:
$ip = az vm show -d --resource-group DemoRSC --name CHRVM --query publicIps -o tsv
Winbox is also working, but for this, first you have to create a rule in the automatically-created network security group,
which controls the VM’s network traffic. The network security group
belongs to the VM’s network interface resource not the VM, so this
configuration is a littlebit easier on GUI.
Create an inbound rule for Winbox 8291 port.
Now you can connect to the CHR’s public IP with Winbox and SSH too.
Enjoy your MikroTik router in Azure! 🙂
interfaces, IP addresses and routes are a littlebit complex but not
impossible. You have to know how Azure networking works. See my next
WARNING: Winbox and SSH with username/passsword via a public IP address is very unsecure but it’s just a demo. Secure your connections in productional environment!