Now we’re getting very close to a completed solution – all that is left to consider are those pesky things called certificates. In previous releases this was an important consideration. That’s because in previous releases we had a fully-fledged ‘web portal’ which users could access via Internet Explorer, rather than using the fully blown client. VMware has now depreciated this functionality. As such the web portal now only acts a page to download the View client(s). However, to be complete I’ve opted to keep this in my guide. I also hope that VMware might reconsider the removal of the web portal and re-instate it in future releases.
I’ve been dealing with certificate technology for nearly ten years, and while they have come down in price since the days that Verisign and Thawte charged the earth for them, the generation and enrollment process is still fraught with administration, not least because each software vendor seems to prefer their own tools. There seems to be a bewildering array of certificate types, and in some cases the documentation seems to be decidedly lacking, precisely because there are so many different ways of managing the process. For this reason I’m going to assume you only have a passing understanding of certificates, and I hope I don’t patronize too many people along the way.
In the main, certificates are used to prove or validate the identity of the server or service you’re connecting to, with the intention of reassuring the user or customer that they have connected to a genuine website. The lynch pin of certificates is the concept of trust. You trust the certificate offered up by https://www.hotmail.com because an Authority created it that you trust. Specifically, your web browser has a list of trusted “root” certificate authorities (the people who issue certificates) built-in, including companies like VeriSign and Thawte. These authorities are meant to check out certificate applicants and revoke certificates that have been abused by rogue operators. The trouble is, they charge fees for their services, and there have been occasions in recent memory where the checking hasn’t been as rigorous as it should be. The sad reality is that you can still go to a secured website that takes a payment, and then promptly shuts up shop the day after. Despite the rise and rise of e-commerce and a global financial system (are those terms sounding a bit hollow in Q2 of 2010?) consumer protection law seems to vary greatly, even from one part of the United States or the European Union to another.
The process of applying for certificates could be considered analogous to the way the passport system is generally managed. The root CA authority is like the national government, this body allows for the existence of the passport office (the Certificate Issuing Authority or sub-ordinate). The authority receives applications for passports from individuals who need to prove their identity to others (the certificate for the website). An application process is made by the individual, and then the authority (the passport office) decides whether to allow or deny the application. The application process creates a private key that is used for encryption purposes. This private key is like a passport application together with all the other supporting documents required to validate the request (like your birth certificate and driving license). Until it is stamped or trusted by a recognized authority, it remains just a fancy piece of paper. These components need to be secured because if they were intercepted it would undermine the whole application procedure.
Occasionally, a certificate can be revoked if this relationship breaks down. The certificate authority can publish what are called revocation lists denying the authority of the certificate in question. You can liken this to when an individual commits a crime, and their freedom to travel is deliberately limited.
Alongside confirming the identity of the web server in question, the certificate also allows for encryption of data packets to and from the client and the server using the Secure Sockets Layer (SSL) originally developed by Netscape. SSL is the S you see in https://. Many web browsers now check the authority and validity of certificates which you will have seen countless times in iLO/DRAC/RAC boards and indeed in VMware products, which use internally self-signed certificates for Web Access and the vSphere Client. Indeed, nowadays the most common reason to generate certificates that are valid, is to prevent users overreacting to various warnings and error messages generated when a certificate is not trusted. In the main, this is caused by lack of knowledge of what a certificate is, and the general paranoia about security of all web servers and sites – even intranet portals. Anyway, that’s the end of the Sesame Street view of certificates; I’m now putting my bright yellow chicken suit to one side.
As you have seen, the process begins with a request for a certificate, and VMware use a Java utility called keytool to make the initial request file. Despite both the Connection Server and Security Servers being Windows-based, VMware has chosen not to use Microsoft utilities for the certificate enrollment process itself.
|Want to read more of this guide?
Download the full “Administering VMware View 4.5” Guide (21 Chapters). The full guide contains additional step-by-step instructions and screen shots in each chapter.
This was first published in September 2010