View Only
  • 1.  Replacing Default Certificates

    Posted Jul 10, 2014 02:20 PM

    Hi, we are running a vCenter 5.1 U1c environment, along with SSO 5.5.  SSO is installed on a different Server to vCenter/WebServices.

    I have created all the necessary certificates, however when using Automation Tool 1.0.1 to update the SSO Certificates I get the error:

    The service is not installed on that machine.

    I have checked the SSO Services and the following services have all started:

    * VMware Certificate Services
    * VMware Directory Services
    * VMware Identity Management Services
    * VMware KDC Services
    * VMware Secure Token Services

    Any thoughts?

  • 2.  RE: Replacing Default Certificates

    Broadcom Employee
    Posted Jul 14, 2014 05:31 PM

    When applying certs for SSO , are you running SSL Automation tool on vCenter Machine or SSO machine .

    If SSO is installed on a separate machine then SSL Certificate Automation Tool must be deployed on the machine running the services.

    Reference KB -

  • 3.  RE: Replacing Default Certificates
    Best Answer

    Posted Jul 15, 2014 05:34 PM

    How to replace default certificate for SSO  5.5 ? The steps are below.

    Perform these steps on machines where Single Sign-On is installed:

    1. Back up the vmdircert.pem and vmdirkey.pem files (located at C:\ProgramData\VMware\CIS\cfg\vmdird).

    2. Copy the current vmdircert.pem file and save it as vmdircert.crt.

    3. Double-click the vmdircert.crt file to open it and click the Details tab. Scroll down to Subject Alternative Name and record the IPv4 and DNS name.

    4. Open a Windows command prompt as Administrator and create a temporary directory using this command:

      This example uses C:\temp:

      mkdir C:\temp

    5. Navigate into the directory using this command:

      cd C:\temp

      Note: The new Key and Certificate generated in this procedure will be initially stored in the temp directory.

    6. To generate a new Private Key, run this command:

      "C:\Program Files\VMware\Infrastructure\VMware\CIS\vmcad\certool.exe" --genkey --priv=priv.key --pub=pub.key

    7. To generate a new Certificate, run this command:

      Note: Replace FQDN_DNS_NAME and IP_address with the DNS and IPv4 values respectively as recorded in step 3:

      "C:\Program Files\VMware\Infrastructure\VMware\CIS\vmcad\certool.exe" --genCIScert --priv=priv.key --Name=VMWareDirectoryService --FQDN=FQDN_DNS_NAME --IP=IP_address --cert=cert.crt --port=11711

      Note: For environments in which multiple hostnames or IP addresses are used, use the following command structure similar to the command listed above:

      "C:\Program Files\VMware\Infrastructure\VMware\CIS\vmcad\certool.exe" --genCIScert --priv=priv.key --Name=VMWareDirectoryService --FQDN="FQDN_DNS_NAME1,DNS:FQDN_DNSNAME_2,DNS:FQDN_DNSNAME_3" --IP="IP_address1,IP:IP_address2,IP:IP_address3" --cert=cert.crt --port=11711

    8. Copy the new Private Key to the Single Sign-On VMDir configuration location using this command:

      copy priv.key C:\ProgramData\VMware\CIS\cfg\vmdird\vmdirkey.pem

      Note: If asked to overwrite the existing file, answer Yes.

    9. Copy the new Certificate to the Single Sign-On VMDir configuration location using this command:

      copy cert.crt C:\ProgramData\VMware\CIS\cfg\vmdird\vmdircert.pem

      Note: If asked to overwrite the existing file, answer Yes.

    10. Restart the VMware Directory Service on all Single Sign-On servers:

      1. Click Start > Run, type services.msc, then press Enter.
      2. Locate the VMware Directory Service and click Restart.

        Note: You must restart the service on both Single Sign-On servers.
    11. Verify that you can continue to log into vCenter Server.

    Please see the below kb article for more info.

    VMware KB: Resolving OpenSSL Heartbleed for VMware vCenter Server 5.5

  • 4.  RE: Replacing Default Certificates

    Posted Jul 16, 2014 03:20 AM

  • 5.  RE: Replacing Default Certificates

    Posted Jul 16, 2014 07:19 AM

    Thanks.  I managed to resolve it.  We were running vCenter 5.1 but also running SSO 5.5 on a separate workstation.  So I ran the correct Automation Tools with the corresponding versions and this worked.