Showing posts with label certs. Show all posts
Showing posts with label certs. Show all posts

Tuesday, February 5, 2019

VMware Recertification Rollback


Whoever thought we'd see this?! VMware made an overwhelmingly well-received change today regarding its VCP Certification program. Effective immediately, VMware is removing the requirement to recertify their VCP certifications within a two-year period. The decision to update and recertify is left up to YOU!

What does this mean for your expired certifications?
If you hold any of these previously expired certs, it will flip to showing Active starting in April 2019. If your cert changes to being active, you can complete the upgrade path to earn the latest version - no more expired cert upgrade path!


What if you spent time and money re-certifying one of these newly active certs?
VMware will provide you a free one-year premium license to the VMware Learning Zone - assuming you certified within the last 6 months.

Check out the official Blog Announcement and happy certifying!
Share:

Thursday, August 27, 2015

Demystifying Horizon View Certs - Easily install a signed certificate

Horizon View certs giving you a headache? Follow this post to take away the complication and get those servers green! This post will cover installing certs for all versions of VMware View (Horizon).

Disclaimer: This post is based off KB 2068666
Generate the Certificate Request

We'll be using the Microsoft Management Console (MMC) Certificates Snap-in.

  1. From your Connection Server or some other Windows Server click Start > Run > MMC

  2. Click File > Add/Remove Snap-in...
    add-snap-in

  3. Highlight Certificates and click Add >
    add-snap-in

  4. Choose  Computer account and click Next

  5. Choose Local Computer > Finish
    snap-in2

  6. Ensure you see Certificates (Local Computer) under Selected snap-ins and click OK

  7. Expand Certificates (Local Computer) and right click Personal > All Tasks > Advanced Operations > Create Custom Request
    create-custom-request

  8. Per the splash screen, verify the computer is connected to the network and you have credentials that can be used to verify your right to obtain the certificate and click Next

  9. Under Custom Request, highlight Proceed without enrollment policy and click Nextenrollment-policy

  10. Select No Template Legacy key from the drop down and ensure PKCS #10 is selected. Click Next
    enrollment-policy2

  11. Expand Details and click Properties
    request-properties

  12. On the General tab, type vdm for the Friendly name
    vdm

  13. Click the Subject tab and enter the below values

Common NameValue = FQDN of View ServerClick on Add Button
CountryValue = (2 Letter Country Code, e.g., US)Click on Add Button
LocalityValue = (Your City Location)Click on Add Button
OrganizationValue = (Your Company)Click on Add Button
Organization UnitValue = (Department, e.g., IT)Click on Add Button
StateValue = (2 Letter State Code, e.g, CA)Click on Add Button

cert-properties



  1. Click the Private Key tab > Click on Key Options Details > Select Keysize 2048

  2. Check the box for Make private key exportable and click Ok > Next
    exportable

  3. Save the file as a .req
    certreq

  4. Provide this certreq.req file to your Certificate Authority per their requirements.

Installing the Certificate

Once the 3rd Party CA has provided you the certificate, download the necessary files (in most cases this would be the Tomcat/P7B/bundle provided by the CA). If they provide host, intermediate, and root certs, download all 3 files. Now we'll launch MMC on the Connection Server to install the cert.

  1. Assuming the MMC console is still open and the cert snap-in is enabled, expand Certificates (Local Computer) > Personal > Certificates

  2. Right click and choose All Tasks > Import
    Import

  3. Select the cert bundle you downloaded
    Picture1NOTE: Make sure that whenever you're prompted you choose:

    • Yes to Mark the Private Key Exportable

    • Yes to all extended properties

    • Yes to all certificates in the certification path

  4. Choose Automatically select the certificate store based on the type of certificate and click Next
    Picture3

  5. Finish the Import wizard.

NOTE: If importing a PFX file, you will be prompted for the private key password. Check both boxes to mark as exportable and include all extended properties
Picture2


Important: Completing the certificate installation

If you're on View 5.1 or later, you're done! All you need to do is restart the View Connection Server Service for it to pick up the new certificate. After the service starts, wait up to 5 minutes before the View Admin page reflects the Green status.

If you're on View 5.0.x or earlier, you must now export the cert as a PFX from the MMC console, place into the local SSL directory, and update your locked.properties file with the cert's path.

  1. Copy the PFX you exported to the SSL Gateway directory on the Connection Server (usually install_directory\VMware\VMware View\Server\sslgateway\conf)

  2. Edit locked.properties in the same directory to contain the PFX file name and password you set during export (if you don't have a locked.properties file, you'll need to create it)
    keyfile=key.pfx
    keypass=secret

  3. Restart the Connection Server service

If this post helped you get your cert installed, let me know in the comments! Good luck!
Share:

Monday, December 15, 2014

Workspace Portal SSL Certificates [updated for vIDM]

[Updated September 2015]


The below process was originally written for Workspace Portal 2.1 and can be applied to vIDM. Any differences in process has been placed appropriately within the post.




VMware strongly recommends that you configure SSL certificates that are signed by a valid Certificate Authority (CA) for use by Workspace Portal.

A default SSL server certificate is automatically generated when the Workspace appliance is installed. Although you can use the default, self-signed certificate for testing purposes, it should be replaced as soon as possible for a production environment. The default certificate is not signed by a CA. Use of certificates that are not signed by a CA can allow untrusted parties to intercept traffic by masquerading as your server.

If you deploy Workspace with the self-signed SSL certificate, the Workspace root CA certificate must be available as a trusted CA for any client who accesses Workspace. The clients can include end user machines, load balancers, proxies, and so on. You can download the Workspace root CA from https://workspacehostname.com/horizon_workspace_rootca.pem.

Before you can import a certificate, you must generate a Certificate Signing Request (CSR) and obtain a valid, signed certificate from a CA. If the CSR is not generated according to the example procedure described in this document, the resulting certificate and its private key must be available in a PEM format file.

There are many ways to obtain SSL certificates from a CA. This post shows how to use OpenSSL to generate a CSR and make a certificate available to Workspace Portal. You can use another method if you are familiar with the required tools, and they are installed on your server.

If your organization provides you with SSL certificates that are signed by a CA, you can use these certificates. If these certificates are not in the necessary PEM format, you can convert them with third party tools, such as that from SSLShopper

To make a certificate available to Workspace Portal 2.1, three things must be done:

  1. Create a configuration file

  2. Generate a certificate signing request (CSR) from the configuration file

  3. Send the signing request to a CA


When the CA returns the certificate, you must import the signed certificate into Workspace Portal using the Appliance Configurator. If using a Load Balancer, you must import the signed certificate onto to the Load Balancer per the vendor's instructions, and then install the Load Balancer's Root CA Certificate on Workspace Portal.

Creating the configuration file


We will be using OpenSSL as it comes pre-installed on the Workspace Portal appliance, though you can use OpenSSL on a wide variety of operating systems, including Windows. The below instructions will be assuming a Linux based OS.




  1. Login to your system that has OpenSSL installed (if using the Workspace appliance, either open a vSphere console, or SSH into the appliance).

  2. Create a folder to perform the certificate work in:mkdir certificates
    cd certificates

  3. Copy openssl.cnf into that foldercp /etc/ssl/openssl.cnf openssl.cnf

  4. Edit the file using vi.
    vi openssl.cnf
    The part of the file you have to modify in order to generate a certificate request is highlighted below. For a wildcard certificate request, subjectAltName is not relevant.



[ req_distinguished_name ] # Change these settings for your

environment

countryName_default = US

stateOrProvinceName_default = Colorado

localityName_default = Broomfield

0.organizationName_default = EUC

organizationalUnitName_default = IT



 

[ CA_defaults ] # Change sha1 to sha512

default_md = sha512

 

[ req ]

default_bits = 2048



[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment,

dataEncipherment

extendedKeyUsage = serverAuth, clientAuth

subjectAltName = DNS: ext-con.company.com, DNS:

view.company.com, DNS: gtw.company.com, DNS:

services.company.com Since we will request a wildcard

certificate these additional hostnames are not of importance.



NOTE: We are not setting the commonName here, we will do that below when prompted. If you plan to not use a wildcard, consider adding your subjectAltNames




Save this file

:wq


Generating the certificate request




  1. Create your CSR and private key by typingopenssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cnf


  2. Accept the default values you configured on the .cnf file. When prompted for the common name, enter either the wildcard value, or the external name you will be referencing for Workspace from outside your network (e.g., portal.acme.com)Make sure you store your private key in a safe place. Without it, your certificate becomes useless.

  3. Congrats! You've successfully created a certificate signing request for a sha512 hashed, 2048-bit encrypted certificate. Now to get this CSR signed.


Send the CSR to a Certificate Authority (CA) for signing



Your CSR must be submitted to a CA in order to be issued a usable certificate. You can use either a publicly trusted CA (GoDaddy, DigiCert, etc), or an internal CA your company has, or perhaps one you even built yourself. If you don't go with a publicly trusted CA, there are plenty of options for setting up your own CA. The important thing to ensure is when you've been issued your certs, download them as Base 64 encoded.

Installing the certificate


Once you've obtained your certificate(s), it's time to put it together so that Workspace can understand it. Workspace needs the certificate to be in PEM format. PEM is a widely used format these days because of its flexibility and ease of use. PEM allows you to bundle multiple certificates into a single file which a server can read and understand. This is important for Workspace. If you need to convert the certs you received to PEM format, you can use the link provided earlier in this post, or even use OpenSSL. Workspace needs at least 2 certs (usually 3) which you should have received from your CA.

Server (host) cert
Intermediate cert(s)
Root cert

This is how we will build our PEM file, with the host cert on top, any intermediate certs in the middle, and root on the bottom:
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate)
-----END CERTIFICATE----

It's important to use a text editor like WordPad or Notepadd++ when handling these PEM files. Using something like Notepad can cause formatting issues that we certainly want to steer clear of.

Once you've built your new PEM file containing the components above, it's time to install it. If you don't have a load balancer or reverse proxy server in place, you can install this right on Workspace. This is considered terminating SSL on the Workspace Appliance.

To do this on Workspace Portal:

  1. Login to the Appliance Configurator (https://your_workspace:8443), click Install Certificate

  2. In the Terminate SSL on Workspace appliance tab, paste the complete certificate chain (what we created above) and also include the private key in its box.

  3. Save the SSL certificate.


To do this on vIDM:

  1. In the Administration Console, click Appliance Settings

  2. Click Manage Configuration and enter the admin password

  3. Click Install Certificate

  4. In the Terminate SSL on Identity Manager Appliance tab, select Custom Certificate.


If you're using a Load Balancer or Reverse Proxy, you'll need to instead install the cert on that device per the vendor's instructions. Using something like NGINX is quite simple as you simply include the cert and private key path in the configuration file (See How to Setup NGINX as a reverse proxy for Workspace Portal 2.1)

If you're using an internal CA, or otherwise a lesser known CA, it may be necessary to install the Root CA on Workspace in order for it to gain trust. Back at the Install Certificate page, click the Terminate SSL on a Load Balancer tab, and paste the PEM output of the Root CA here.

NOTE: if you've previously installed custom certs on Workspace itself, and are now trying to instead use a Load Balancer, you will need to first re-generate the self signed certs on Workspace before you'll be able to properly reconfigure the Workspace FQDN.

[Important]
If you happen to use a KEMP load balancer with Workspace, you may run into issues configuring your FQDN after following the recommended SSL Certificate process. Please review Kemp's Workspace Documentation which should help get the load balancer configured properly.

Related documentation and references




Share: