Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

April 28, 2021

I Was a Panelist Discussing Challenges of a Hybrid Workforce with Citrix

Introduction:

For those that are not aware, I recently made the move to join Liquidware as a Sales Engineer and subsequently moved away from my long tenure in consulting, while I am greatful for all of the customers and companies that I worked with. Sales Engineering has always been a goal of mine to formally get into and things have been great so far. In my role as a Sales Engineer, I am always asked to present and discuss not only Liquidware's products but present on past experiances I have had implementing virtualization with customers. Recently I was tab to speak on Liquidware's Unplugged webinar about The Challenges of a Hybrid Workforce with Calvin Hsu who is the V.P. of Product Management at Citrix and Jason Smith VP of Product Marketing at Liquidware.

For those of you that are not aware, Liquidware's Unplugged Webinar series is interactive webinars that are built exclusively for the end-user computing (EUC) community. More information can be found on Unplugged here.

Recording:

Here is the recording of the Unplugged Session with Calvin Hsu.


Hopefully this webinar is a first of many that I will be able to participate in going forward. Please use the link above to stay up to date with future Unplugged sessions.

We would like to hear from you so feel free to drop us a note if you have any questions.

Johnny @mrjohnnyma



April 19, 2021

Replacing a Self-Signed Certificate on vCenter 7.x +

Purpose:

Demonstration on how to replace the self-signed certificate on VMware vCenter.

Introduction:

Having valid certificates is not only crucial today and going forward, it has been crucial for the last few years as well. Having valid certificates not only ensures that a certain security posture being maintained, it removes any unsightly certificate warnings that make various products unfriendly to use for the administrators/engineers/architects.

I recently made a transition from Nutanix Community Edition (CE) to VMware vSphere in my home lab due to upgrade issues with the most recent release of CE. VMware vSphere 7.x and above resolved an issue where the NIC in an Intel NUC 10 was not detecting during installation and the driver needed to be sideloaded before CE could be installed. This is a continuation of my blog series where I take a focus in on security from a virtualization standpoint. Here is a similar themed blog about how to replace the self-signed certificate in Nutanix Prism Element and Prosim Central.

Today we will talk about how to replace the certificate on vCenter and how significantly easier it has become to do so. Before I start, I am going to preface this that process only applies to VMware vCenter 7.0 and above at the time of this writing. If folks are still running a vCenter 6.5 or 6.7 this will not work there as the process is completely different. Also this not only affects Citrix, it affects VMware Horizon and any other solutions that integrate into vCenter.

How many of us have in the past or even today check the box on this message to acknowledge and trust the self-signed certificate in an on-prem or cloud based full Citrix Studio?


Most of us probably click through it without second thinking why  the warning applies or also just wave it off as “that is not my problem and it is the vSphere team’s problem”. While it may be the vSphere teams problem, security should be a concern from all IT folks as there are always ways that system compromises can easily be fixed if there was a security first mentality. In addition to this, replacing the certificate will remove the warning from vCenter when folks use the vCenter web console. 

In vCenter 7.0 and above it is very easy to replace the certificate so that the warning never even pops up when establishing the Hosting connection string from Studio. 

Configuration Steps:

First we will need to create a certificate, in my case I will be using a domain certificate authority (CA). A certificate from a 3rd party well trusted CA can also be configured in this manner as well. 

I find it easier to generate the CSR on the vCenter and later will have some interesting issues from generating the CSR elsewhere.

Go to vCenter and login as administrator@vsphere.local (this is the only account that has permissions to change the certificate management) On the Top, go to Menu -> Administration

On the left pane -> Click Certificate Management

Under Actions -> Click Generate Certificate Signing Request (CSR)

Fill out the information appropriately -> Click Next

Copy or Download the CSR -> Click Finish

Open a browser and go to https://domainca.fqdn.com/certsrv replacing with your domainca FQDN. In my case it is domain1.domain.lab. -> Click Request a Certificate

Click Advanced Certificate Request

Click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file

Copy and paste the contents of the CSR file generated earlier into the large field -> Select the appropriate certificate template -> Click Submit

After submitting the certificate may be pending if the CA is configured for approval (as such in my lab). Get the proper approval to issue the certificate

After approval go back to https://domainca.fqdn.com/certsrv -> Click View the Status of a Pending Certificate Request

Click on the Request from earlier -> Click on the Request
Select Base64 encoded -> Download the Certificate

Save with to a location where it can be accessed with an appropriate name –> Click Save


The domain CA’s root and intermediate certificates are required to be exported as .cer as well. In my case, these can be found on the domain controller under Certificate Manager for the Local Machine -> Trusted Root Certificate Authorities Certificates.

Back on vCenter -> Administration -> Certificate Management we need to import the Root and intermediate certificates so that the cert is trusted. -> Click Add

Browse to the root cert -> Click Add

After adding, there are now multiple Trusted Root Certificates

For the Machine Cert section Click Action -> Import and Replace Certificate

Select Replace with external CA certificate where CSR is generated from vCenter Server (private key embedded) as the CSR was generated on the vCenter -> Click Next

On the first field -> Click Browse File and select the certificate that the Domain CA issued. On the second field -> Click Browse File and select the domain CA root certificate that was exported. If there are both root and intermediate certificates they may need to be combined in notepad –> Click Next

vCenter Services will automatically restart which will take a few minutes. It is common to get this message as services are restarted.

When vCenter is back and ready log back in and go to the Certificate Management section. The Machine cert should have an updated expiration date. Track that date and make sure to repeat the process again before the certificate expires to ensure everything continues to run smoothly for any services that integrate with vCenter.

There also are no longer certificate warnings when going to the vSphere web client and when the certificate is viewed, it is the appropriate certificate

The Hosting section in Studio connects to vCenter without a warning now as well.

If you tried to generate the CSR outside of vCenter and went through the process of generating the certificate. You could get this error like I did. There really isn’t a reason why the character was invalid but this is why I recommend generating the CSR on vCenter.

Conclusion:

VMware has made it significantly easier to replace the certificate in vSphere 7.x then it was in 6.x. It makes it almost a no-brainer to do this in my opinion. We didn't need to incure any additional costs as the certificate was generated from a domain CA, but this process would work if you need to get a signed certificate from a third party CA. If we take an overall approoach of focusing in on security in each layer of the infrastructure, we significantly improve the security posture of the entire environment and eliminate as many security flaws in the environment as possible.

We would like to hear from you so feel free to drop us a note if you have any questions.

Johnny @mrjohnnyma

October 12, 2020

How to Replace the Self-signed Certificate for Nutanix Prism Element and Prism Central

Purpose:

Demonstration on how to replace the self-signed certificate on Nutanix Prism Element and Prism Central.

Introduction:

There are many blogs out there about how to replace the self-signed certificate in Nutanix Prism Element and Prism Central with a domain signed certificate. A lot of the blogs reference the need to create the Certificate Signing Request (CSR) in the command line of OpenSSL on a Linux or Windows machine. There are alternatives to this, the certificate can very easily be created using the Microsoft certificate snap-in and then using OpenSSL to convert the certificate into an acceptable format for Prism Element and Prism Central to use. This is useful as a lot of workloads (Citrix, VMware, etc...) are being migrated to Nutanix for the hyper-converged benefits and this eliminates the certificate warning and improves security posture for the environment.

Configuration Steps:

Launch the Microsoft Certificate Snap-in for the Local Computer.

In this case I going to create a custom request as I want to be able to define the Subject Alternative Name and use the same certificate for Prism Central and Prism Element. At a minimum there at least needs to be one Subject Alternative Name which is the Common Name or popular browsers such as Mozilla Firefox, Google Chrome or Chromium Edge will produce a certificate warning stating the Subject Alternative Name is missing.

Clikc on Personal node -> Right Click in the Certificate Snap-in -> go to All Task -> Advanced Operations -> Create Custom Request.


Click Next

Since we are creating a custom CSR and do not want to be dependent on an Active Directory Enrollment Policy, select Proceed without an Enrollment Policy

On the Template dropdown, select (No Template) Legacy Key -> Click Next

Expand Details -> Click Properties

On the Friendly Name fill in the friendly name of the certificate. In my case prism.domain.lab.

Fill in all of the certificate details such as the Common Name, Organization, Organizational Unit, Locality and State under the Subject name section. Under the Alternative Name section fill in All of the Alternative Names, in my case prism.domain.lab, prism, prismcentral.domain.lab and prismcentral. This allows for both short names and fully qualified domain names to not produce certificate warnings. 

Under the Private Key tab make sure that the Key Size is 2048 bit (always use this) and that Mark private key exportable is checked or after completing the signing the certificate cannot be exported. -> Click Apply

Save the CSR to a location for easy access

Now head over to your Domain CA Web Enrollment portal, typically from a browser go to: https://domaincafqdn/certsrv. Click Request a certificate.
Click advanced certificate request

Click Submit a certificate request by using a base-64 encoded CMS or PKCS #10 file


Open the CSR generated earlier, copy and paste the contents of this into the base-64 encoded certificate request or PKCS #10 or PKCS #7 field. On the Template select the appropriate Web Server Template defined by your Domain CA administrator. In my case Web Server 2048Bit SHA256.

Once the CSR has been submitted and the request has been answered by the domain CA the file should be saved in a place for easy access. In my case the file is named prism.domain.lab.answer.cer

Now back on the machine where the CSR was generated in the Microsoft Certificate Snap-in Right Click -> All Tasks -> Import 

Click Next


Click Browse


Browse to the previous location where the answer file was saved. -> Click Open


Click Next


Make sure the Personal Store is selected -> Click Next


Confirm settings -> Click Finish

Now the certificate needs to be exported as a PFX file which contains the private key. When exporting from Windows the private key is encrypted with a password. This will need to be retained in order to perform the next steps in OpenSSL which will extract the certificate pieces and remove the password on the private key.

We can extract the private key from a PFX to a PEM file with this command:
# openssl pkcs12 -in filename.pfx -nocerts -out key.pem

Exporting the certificate only:
# openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem

Removing the password from the extracted private key:
# openssl rsa -in key.pem -out server.key


Open the .key file and remove the bag attributes and issuer information or Prism Element and Prism Central will not be able to use it. In addition the intermediate and root certificates for the Domain CA need be available and if there is both an intermediate and root they should be copied into a single file and simply named with a .cer format.


Login to either Prism Element or Prism Central


In the settings, go to SSL Certificate -> Click Replace Certificate



Make sure Import Key and Certificate are selected -> Click Next

RSA 2048 should be selected by default. Select the appropriate files. In my example prsim.domain.lab.key for the Private Key, prism.domain.lab.cert.pem for the public certificate and domain1.ca.cer for the CA certificate chain -> Click Import Files

It may take a few moments and the window should reload and now there no longer is a certificate warning on Prism. The certificate installation is the same for both Prism Element and Prism Central.

The certificate can be viewed and it should be the same certificate from before.