Appendix B: Security : Secure Certificates : Secure Certificates Example
   
Secure Certificates Example
Deployment models: private, public, hybrid.
In the vCloud environment Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols provide secure communication between the end tenant (client) and vCloud Director cell (server). The secure communication includes confidentiality and privacy of communication, message integrity and hashing, and authentication.
Web browsers display a warning message indicating that a site’s identity cannot be trusted if a certificate has expired, or the certificate was issued by a certificate authority that is not trusted. It is the primary role of SSL/TLS to provide confidentiality and privacy of the communication, and to prevent MITM (man-in-the-middle) attacks, side channel attacks, and tax intended to compromise your privacy and security.
Figure 60. Example Error Message
 
Message Integrity and Hashing is the ability to guarantee that the data has not been modified during the protocol exchange and transmission.
Using certificates for authentication is a process of confirming identity. In the context of network interactions, authentication is the identification of one party by another party, and certificates are one way of supporting authentication.
Certificates or digital certificates are collections of data that uniquely identify and verify an individual, company, or other entity on the Internet. Certificates also enable secure, confidential communication between two entities. In the context of vCloud Director, server certificates are used to establish secure sessions between the cell server and clients using SSL and TLS.
The following figure shows the address bar for a web site that has been secured using SSL/TLS. The URL begins with https, and a padlock symbol is shown in the top right far corner of the browser.
Figure 61. Web Site Address Bar
 
Types of SSL certificates are the following:
*Self-Signed certificate – Generated for internal purposes, not issued by a certificate authority (CA).
*Domain-signed certificate:
*An entry level SSL certificate that can be issued quickly.
*The only check performed is to verify that the applicant owns the domain where they plan to use the certificate.
*No additional checks are done to confirm that the owner of the domain is a valid business entity.
*Fully authenticated SSL certificate:
*First step to true online security and confidence building.
*Takes slightly longer to issue because these certificates are granted only after the organization passes a number of validation procedures and checks to confirm the existence of the business, the ownership of the domain, and the user’s authority to apply for the certificate.
*Server Gated Cryptography (SGC)-enabled SSL Certificate – Used for old browsers or clients that do not support 128/256 bit encryption.
*Wildcard certificate – Allows full SSL security to any host in domain.
*SAN (Subject Alternative Name) SSL certificate – Allows more than one domain to be added to a single SSL certificate.
*Code signing certificate – Specifically designed to make sure that downloaded software was not tampered with during the download.
* Extended Validation (EV) SSL certificates – Offers the highest industry standard for authentication and the highest level of customer trust.
For a private, hybrid, or public vCloud provider, VMware recommends implementing SSL certificates from a Trusted CA.
The following process flow outlines all of the steps to request, configure, obtain, and install an SSL certificate from a CA that can be used as for a CA for vCloud Director.
Figure 62. Requesting, Configuring, Obtaining and Installing an SSL Certificate from a CA
 
The following guidelines apply when considering SSL certificates:
*Understand and evaluate the different types of SSL certificates that are available and use one that matches your requirements.
*In a production environment, do not configure vCloud Director to use self-signed certificates. This is an insecure practice. Self-signed certificates are certificates that are digitally signed by the private key corresponding to the public key included in the certificate. This is done in place of a CA signing the certificate. By self-signing a certificate, you are attesting that you are who you say you are. No trusted third-party validation is involved.
*Self-signed certificates do not have a valid chain of signatures leading to a trusted root certificate and provide a weaker form of security. Although you can verify such a certificate is internally consistent, anyone can create one, so by examining the certificate, you cannot know if it is safe to trust the issuer or the site from which the certificate is coming. Nevertheless, self-signed certificates are common. For example, vCenter installations use a self-signed certificate by default.
*The server keystore highly sensitive because a compromise of the server key allows impersonation of the server and/or access to the encrypted traffic. Java keystores provide a password-protected method of securely storing private keys and their associated certificates. vCloud Director supports only the JCEKS format for keystore files. (Other formats that Java supports include PKCS12 and JKS. JKS is less secure and not recommended).