VMware VCM 5.3 - TRANSPORT LAYER SECURITY... Manual de usuario

vCenter Configuration Manager

Transport Layer Security

Implementation

VMware VCM 5.3

WHITE PAPER

TECHNICAL WHITE PAPER / 2

Table of Contents

Introduction to TLS 4

Server Authentication 4

Mutual Authentication 4

Certificates and Public Key Infrastructure 5

Expiration and Revocation 5

Certificate Standards 6

Certificate Storage 6

How VCM Uses Certificates 7

The Enterprise Certificate 7

The Collector Certificate 10

Agent Certificates 10

TLS Machine Security Level 11

Creating and Installing Certificates for Collectors 12

Installation of Certificates to Collectors 12

Installation of Certificates to Additional Collectors 12

Changing Certificates 13

Renewing Certificates 13

Replacing Certificates 13

Delivering Initial Certificates to Agents 15

Installing the Agent from the Collector 15

New Installations 15

Upgrades 15

Changing Protocols from DCOM to HTTP 15

Changing Protocol from HTTP to DCOM 15

Installing the Agent from a Disk (Windows only) 16

Using CMAgtInstall.exe via Network Share to Install the Agent (Windows only) 16

UNIX/Linux or Mac OS X 16

Installing the Agent Using a Provisioning System 16

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 3

Certificate Expiration 17

Certificate Transport 17

Exporting Certificates (Windows Only) 17

Importing Certificates (Windows Only) 18

Appendix A: Creating Certificates for TLS Using Makecert 20

Create the Enterprise Certificate and the First Collector Certificate 20

Create Certificates for Additional Collectors 21

Import the Certificates on the Collector Machines 23

MakeCert Options 23

Appendix B: Updating the Collector Certificate Thumbprint in the VCM Collector Database 26

Appendix C: Managing the VCM UNIX Agent Certificate Store 27

Using CSI_ManageCertificateStore 27

Setting up the Command Line Environment for CSI_ManageCertificateStore 27

CSI_ManageCertificateStore Options 28

CSI_ManageCertificateStore Output 30

CSI_ManageCertificateStore Examples 30

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 4

Introduction to TLS

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that

provide endpoint authentication and secure communications over any transport. TLS is normally associated with

Internet communication but can be applied to any transport layer, including sockets and HTTP. TLS allows for two

levels of security: Server Authentication and Mutual Authentication.

Server Authentication

Server Authentication authenticates the server to the client. When server authentication is used, the end user, or

client, verifies that the server they are communicating with is actually who it says that it is. In the Internet world, your

browser is the client, and a website such as Amazon™ is the server. Millions of clients need to be able to prove that

the site to which they are giving financial information is really Amazon™.

To accomplish this using TLS, Amazon™ provides a certificate issued by a trusted authority, such as Verisign®. If

your browser has the Verisign® Certification Authority certificate in its trusted store, it can trust that the server really is

Amazon™. Typically, the server authenticates the client/user by asking for authentication information, such as a user

name and password.

VCM supports Server Authentication. That is, in VCM environments where TLS is employed, VCM Agents are able to

verify the identity of the VCM Collector (or Collectors) through the use and verification of certificates. A description of

this process is provided later in this paper.

Mutual Authentication

Mutual Authentication authenticates the server to the client, and the client to the server. When Mutual Authentication

is used, both the client and the server provide and validate certificates in order to verify each other’s identity.

VCM is Mutual Authentication ready. This means that Agent certificates can be manually created and registered to

create a Mutual Authentication environment. However, VCM does not support this mode out-of-the-box, or supply any

functionality to aid in the administration of Agent Certificates. Contact VMware Customer Support for instructions.

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 5

Certificates and Public Key Infrastructure

A Public Key Infrastructure, or PKI, is a management system that aids in the administration and distribution of public

keys and certificates. TLS can use certificates managed by a public key infrastructure to guarantee the identity of

servers and clients. Certificates can be created, managed and used by TLS without a PKI. For more information about

manually creating certificates, see Creating Certificates for TLS Using Makecert on page 20.

There are two main types of encryption algorithms:

lSingle Key, symmetric, or secret key encryption algorithms use a single key, which must be kept secret.

lPublic Key, or asymmetric algorithms use a pair of keys. One key is used to encrypt information, the other to

decrypt. The process is reversible. Either key can be used to encrypt. The other must be used to decrypt. Asym-

metric encryption is much slower than symmetric encryption. It is common to use an asymmetric protocol to

securely negotiate a session key, which is a secret key used only for the duration of a single connection. The

public key in a key pair may be freely passed around. However, it is important to verify that you have the key

you think you have, and that it belongs to the entity you think it belongs to. Certificates are a mechanism for

making this identification.

A certificate is a package containing a public key, information identifying the owner or source of the key, and one or

more certifications (or signatures) verifying that the package is authentic.

To sign a certificate, an issuer adds information about itself to the information already in a certificate request. The

public key and identifying information are hashed and signed using the private key of the issuer's certificate.

If you have the public key of the issuer, you can verify that the public key in the certificate belongs to the entity

identified in the certificate (if you trust the issuer). You will have a certificate for the issuer with the same type of

information. The issuer’s certificate is, in turn, signed by another issuer. This is called a certification path, or trust

chain. The path ends when you arrive at a certificate that is issued/signed by itself, or when one of the certificates is

explicitly trusted. The path is trusted if it ends in a trusted certificate. Typically, this means that someone has installed

the certificate in a trusted certificate store.

Expiration and Revocation

Keys and certificates are not designed to be used permanently. Keys can be compromised and circumstances can

change. Certificates are created with a certain period of validity, before and after which they should not be used or

trusted. If any certificate expires (the "valid-to"/"not after" date passes without renewing or replacing the certificate),

then it cannot be used to establish a TLS session.

In addition, certificates can be revoked before they expire to indicate the withdrawal of trust. The issuing authority may

make a certificate revocation list (CRL) available as additional validation for certificates it has issued. Any certificates

in the list should not be trusted.

To view your VCM certificates at any time in the VCM Portal, click Administration | Certificates. The data grid

displays your certificates and related information and expiration dates.

For information on how to renew or replace your certificates, see Changing Certificates on page 13.

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 6

Note VCM supports certificate expiration. However, it does not support revocation lists. Certificates can be

removed from the certificate stores to effectively "revoke" them.

Certificate Standards

Certificates are defined by the X.509 RFC standard. This standard includes certain standard fields and capabilities.

Those who implement certificates may add additional fields, which can be marked as either critical or non-critical.

These fields are a contract between the creator and consumer. Because they are implementation-defined, an

application might encounter a certificate with fields that it does not understand. The application is obligated to fail

validation on a certificate with critical extensions that it does not understand. Non-critical extensions may be ignored.

One of the non-critical extensions is Enhanced Key Usage. This extension is used to specify the uses for which the

certificate is valid. These usages may include Server Authentication, Client Authentication, Code Signing, and

Certificate Signing.

Certificate Storage

In Microsoft® systems, certificates are stored in certificate stores. Certificate stores may be located in files, the

registry, memory, Active Directory, and other locations. Logical certificate stores provide a unified view of a collection

of physical stores that share common properties. All discussion of Microsoft certificate stores in this document refers

to logical stores. For a description of the logical system stores provided by Microsoft, see Microsoft TechNet:

Certificate Stores.

On UNIX systems, Collector Certificates (for Server Authentication) and Agent Certificates and Agent private keys

(for Mutual Authentication) are stored in a proprietary protected store. Although this store is not encrypted, it is

protected from simple viewing. Use the CSI_ManageCertificateStore utility and the associated help provided with your

VCM UNIX Agent installation package to view or manage the UNIX Agent Certificate store. For more information, see

the VMware vCenter Configuration Manager Installation and Getting Started Guide.

All VCM Agents using HTTP should be able to trust any VCM Collector Certificate, not just the Collector that the

Agent installation package was generated on. This may be via an Enterprise Certificate or through an existing PKI

system. If this environmental requirement is not met, only the Collector that generated the Agent installation package

(and any Collectors that share an Enterprise certificate with that Collector) will be able to communicate with the Agent

using the HTTP protocol. See How VCM Uses Certificates on page 7.

All VCM Collectors should be able to trust any Agent Certificate, even those issued by other Collectors. This may be

via an Enterprise Certificate or an existing PKI system. It this requirement is not met, the Collector will fail to establish

Mutual Authentication with Agents that are certified by another Collector.

TECHNICAL WHITE PAPER / 7

How VCM Uses Certificates

There are three types of certificates that enable HTTP collector-agent communications in VCM:

lEnterprise Certificate

lOne or more Collector Certificates

lAgent Certificates for each Agent (used in optional Mutual Authentication)

Certificate information regarding the Enterprise and Collector certificates is collected in VCM. See Administration |

Certificates.

The Enterprise Certificate

The Enterprise Certificate enables VCM to operate in a multi-collector environment. Agents have the Enterprise

Certificate in their trusted certificate stores, and can use it implicitly to validate any certificate issued by the Enterprise

Certificate. All Collector Certificates are expected to be issued by the Enterprise Certificate. This is critical in

environments where a single Agent is shared between two Collectors.

Figure 1: Dedicated Collector-Agent Relationship

The diagram above illustrates a dedicated Collector-Agent relationship. This type of environment includes two

Collectors (Collector A and Collector B) that each have a dedicated set of Agents that they collect from. Each Agent

has its Collector’s Issuer (Enterprise) certificate.

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 8

Figure 2: Shared Collector-Agent Relationship

As the diagram above illustrates, an Agent may communicate with more than one Collector. In this case, each

Collector has a common Enterprise Certificate. Because both of the Collector certificates were issued by the same

trusted authority, the Agent that is shared between the two can trust both Collector Certificates. This is useful in multi-

collector, Server Authentication environments.

If you employ Mutual Authenticate and if a single Agent is shared between two Collectors, then it becomes necessary

for each Collector to use an Agent Certificate that is issued by a Collector other than itself. This is described as a

shared Collector-Agent relationship.

TECHNICAL WHITE PAPER / 9

Figure 3: Trust Chain in a Shared Collector-Agent Relationship

In addition, for Mutual Authentication in a shared Collector-Agent relationship, each Collector trusts the Agent

Certificate because that Agent Certificate was issued by a Collector Certificate which was, in turn, issued by the

trusted Enterprise Certificate. Since both Collectors trust the Enterprise Certificate, then they can also trust the Agent

Certificate that was issued by a Collector Certificate that was issued by the Enterprise Certificate.

Enterprise Certificates in VCM must have the following properties:

lMust be capable of signing certificate requests.

lThe path length basic constraint, if present, must be at least two if the Collector certificate will be used for issu-

ing Agent certificates. This means that the Enterprise Certificate may issue a Collector Certificate that may

issue Agent Certificates.

lMay be self-signed. If the certificate is self-signed, it will have to be trusted itself. Trust is bestowed by placing

the certificate in the Trusted Root store (Windows) or in the VCM store (UNIX). This represents a VCM-specific

trust chain.

lMay be signed by another certificate in an existing PKI and placed in the trusted store.

lMust be stored in the local machine Trusted Root Certification Authorities store on the Windows Collector and

Agents (Windows only).

lOn UNIX platforms, the Agent has a vendor-implemented certificate store. The Enterprise Certificate(s) must

be added to this store. One will be included during initial installation, and subsequent certificate(s) must be

added manually using the CSI_ManageCertificateStore utility included with your VCM UNIX Agent installation.

TLS Implementation for VCM

TECHNICAL WHITE PAPER / 10

The Collector Certificate

The Collector Certificate is issued by the Enterprise Certificate, and must be usable for Server Authentication and,

optionally, certificate signing (also known as “issuing”). Server Authentication is required to establish a TLS

connection with an Agent. Certificate signing is required to issue Agent Certificates for Mutual Authentication. It is

technically possible to split these functions between two certificates or two Collectors.

The Collector Certificate is used to initiate and secure a TLS communication channel with an HTTP Agent. The Agent

must be able to establish that the Collector Certificate can be trusted. That means that the Collector Certificate is valid

and the certification path starting with the Collector Certificate must end in a trusted certificate. By design, the

Enterprise Certificate will be installed in the Agent's trusted store, and the chain will end with the Enterprise

Certificate.

The Collector Certificate may also be used to issue Agent Certificates. As long as all Collector Certificates are issued

by the same Enterprise Certificate, any Agent Certificate may be issued by any Collector Certificate, and all

Collectors will be able to trust all Agents. Similarly, all Agents will be able to validate all Collector Certificates.

The Collector Certificate and associated private key must be available to the Collector. This certificate will be stored in

the (local machine) personal system store. Collector Certificates in VCM must adhere to the following requirements:

lMust be located in the local machine personal certificate store of the Collector.

lMust be valid for Server Authentication (OID: 1.3.6.1.5.5.7.3.1).

lIf the Collector certificate will be used to issue Agent certificates for mutual authentication:

lIf the key usage extension is present, it must include certificate signing.

lMust be an authority rather than an end certificate.

lIf the path length is set on the basic constraints, it must be greater than or equal to 1.

Agent Certificates

Agent Certificates are used only in Mutual Authentication. The Agent machine either produces a certificate request, or

one is manually produced on the Agent's behalf. A Collector issues a certificate based on this request. Copies of the

certificate are stored on both the Agent machine and the Collector. The Agent's private key should never exist

anywhere but on the Agent machine.

When a second Collector contacts the agent, the Agent makes its certificate available, and the second Collector also

stores the certificate. Note that a second Collector cannot renew an Agent Certificate that was issued by a previous

Collector.

Certificates are also used to encrypt and distribute the ESX and ESXi Web Service credentials (Virtualization) and to

encrypt and distribute the VCM for Service Desk Integration credentials. These certificates may be the same Agent

Certificates used for TLS.

Agent certificates in VCM must adhere to the following requirements:

Este manual sirve para los siguientes modelos

Tabla de contenidos

Otros manuales de Software de VMware

VMware

VMware VSHIELD APP 1.0 - API Instrucciones de funcionamiento

VMware

VMware VCENTER CHARGEBACK Manual de usuario

VMware

VMware VCENTER APPLICATION DISCOVERY MANAGER 6.1.1 -... Manual de usuario

VMware

VMware THINAPP 4.6 - MIGRATING APPLICATIONS TECHNICAL... Manual de usuario

VMware

VMware VCLOUD REQUEST MANAGER Manual de usuario

VMware

VMware GSX Server 3 Administration Manual de instrucciones

VMware

VMware ESX 4.0 - GETTING STARTED UPDATE 1 Instrucciones generales

VMware

VMware ACE Manual de uso y cuidado

VMware

VMware VCENTER CONFIGURATION MANAGER 5.3 Manual de usuario

VMware

VMware VCLOUD API 1.0 - TECHNICAL NOTE Instrucciones de funcionamiento

VMware

VMware VFABRIC TC SERVER Manual de usuario

VMware

VMware VCLOUD REQUEST MANAGER 1.0.0 Manual de usuario

VMware

VMware VC-SRM4-A - vCenter Site Recovery Manager Manual de instrucciones

VMware

VMware THINAPP Manual de usuario

VMware

VMware VCENTER APPLICATION DISCOVERY MANAGER 6.1.1 -... Manual de instrucciones

VMware

VMware VSHIELD APP 1.0 - Manual de usuario

VMware

VMware FUS3-ENG-M-10-CP - Fusion For Mac OS X Manual de usuario

VMware

VMware ESX 4.0 - GETTING STARTED UPDATE 1 Manual de usuario

VMware

VMware VCENTER APPLICATION DISCOVERY MANAGER Manual de usuario

VMware

VMware ZIMBRA Guía de instalación

VMware

VMware VIEW 4.5 Guía de configuración rápida

VMware

VMware VmWare ESX Server 2.12 Deployment Guía de referencia rápida

VMware

VMware VS4-STD-C - vSphere Standard - PC Hoja de instrucciones

VMware

VMware GLOBAL SUPPORT SERVICES Manual de usuario

Manuales populares de Software de otras marcas

COMPRO

COMPRO COMPROFM Manual de usuario

Muratec

Muratec OFFICEBRIDGE ONLINE Manual de usuario

Oracle

Oracle Contact Center Anywhere 8.1 Manual de usuario

Adobe

Adobe 65007312 - Photoshop Lightroom Manual

Avaya

Avaya NULL One-X for RIM Blackberry Manual de usuario

HP ProLiant BL420c Manual de usuario

PS Audio

PS Audio PowerPlay Manual del propietario

Brady

Brady LOCKOUT PRO 3.0 Manual de servicio

Avaya

Avaya Interaction Center Manual de usuario

Texas Instruments

Texas Instruments TI-83 Plus Silver Edition Manual

Novell

Novell GROUPWISE 8 - INTERNET AGENT Manual de usuario

Oracle

Oracle Application 9i Manual de usuario

Acer

Acer RDM Manual de usuario

Canon

Canon Vixia HF21 Manual de usuario

Canon

Canon ZR950 Manual de usuario

Samsung

Samsung Auto Backup Manual de usuario

Polycom

Polycom Vortex EF2201 Instrucciones de instalación y funcionamiento

Brocade Communications Systems

Brocade Communications Systems Brocade 8/12c Manual de usuario