Vehicle Info:

Vehicle Make/Model – 1983 GMC Caballero (El Camino)

Paint:

-  Custom mixed heavy metallic root-beer brown. -  Custom Airbrushed True Fire under Gold Pearl Metallic and Candy Orange old style flames with micro gold dust and silver dust  in first coat of clear. – 8 coats of High Solids European Clear.

Body Mods

-  Molded in air vents in front of rear wheel wells. – Twin Cut outs on hood for raised air cleaners to stick thru. Smoothed over  tailgate.(removed tag bucket) -  Custom fabricated billet flame grill. -  Rear window fabricated stainless steel overlays. -  Custom fabricated rear window 1/4 deck bed cover. -  Custom fabricated front valance under front bumper with hyper white lights. -  Custom modified rear bumper overlays. -  Custom raised 2 dimensional flames imbedded in side mirrors -  One off fabricated Ground Effects. -  Custom fabricated inner front fender well panels. – Custom fabricated lower quarter panel extensions. Custom fabricated one off lower rocker extension.

Interior

- Custom mixed brown / tan tweed upholstery. (Fabrics installed by Tom’s Kustom Upholstery Deland Fl.) -Custom door panels with 2 dimensional flames in panels. – Custom fabricated center console with candy paint. and airbrushed flames. – Custom dash with candy orange paint and 2 dimensional raised flames imbedded in paint. – Custom modified side covers on bench seat sides.  – Custom orange candy painted gauge face plate with custom clock.  – Tach installed in dash face with flamed front face plate. -  Custom Candy Orange panel over storage area with stereo speakers.  -  Custom seat belt face plates with digital printed flames. -  Custom steering wheel modified from a GTO. -  Custom chrome and candy sparkle fire extinguisher. -  Custom made roof console with interior map lighting.-  Custom flush mounted GPS unit in center console

Engine 

-  ZZ4  355 Motor with Chevy hot cam and roller rockers. Putting out over 410 HP- Shaved Aluminum Heads and other small modifications to engine. -  Holley 750 Carb. with modified twin chrome air breathers that stick up thru hood! -  Orange colored Headman headers with dual H- Pipe exhaust thru Magnaflow mufflers. – Custom Chrome Air conditioner pump with raised chrome flames. Chrome 80amp Alternator -  Custom airbrushed true fire effects on brackets and air cleaner system. –  Custom colored matching overlays on all hoses and wiring. – Custom fabricated sculpted flame panels over radiator area.

Drive Train

- Polished 700R4 Transmission with Chrome pan. – 2200-2400 Stall Converter. Professionally built with complete master overhaul kit. Updated 3-4 clutch package(Ray bestos Z-Pack) – Beast input shell, new low/reverse planetary, new prag, roller clutch, new pump assembly.- Corvette servo – Trans-go shift shift.

Other

- American Racing Aluminum Wheels. 10 ” rear / 8″ front.- smoke window Tint on sides and Chrome Tint on rear window. – Custom Dual Tipped exhaust in front of rear wheels.

_____________________________________________________________________________________________________________

Company car was featured in the official GM licensed 2011 calender

Back cover

Month of April

Front cover

Background

The Microsoft Advisory and related information can be found in Microsoft Support KB 2661254. I would encourage you to read this article as the impact is wider than just VMware SRM and other VMware products.

Although I’m going to show you a way of generating self-signed certificates here for the use with SRM I would recommend using trusted CA certificates if possible to reduce the risk of man in the middle attacks. However the effort required to set up a CA and issue the certificates is far more than what I’m about to explain. This is the quick way to work around this problem until you come up with a better solution, which may include getting CA issued certificates.

Note: This process is not officially supported by VMware and says as much in the output of the command. So use this at your own risk and I would encourage you to test it in an isolated environment prior to applying this to any production system. Always take a backup of existing certificates before making any modifications. These instructions should work for any versions of SRM 5.1 and prior.

Generate New Self Signed SSL Certificates for SRM

There is a file called CertGenUtil.exe that is shipped with SRM and used by the installer to create the default self-signed SSL certificates. The version included in 5.0 and prior only generates 512 bit keys, which are not sufficiently strong after you’ve applied the MS patch. The MS patch requires 1024 bit keys or higher. Fortunately the version of CertGenUtil.exe shipped with SRM 5.1 generates 2048 bit keys and can be used to re-generate the certificates for use with versions of SRM include 5.0 and prior. You may need to use this if you are upgrading from SRM 5.0 to 5.1 also as the certificates are not generally replaced during an upgrade process. I have not yet tested the upgrade process of SRM 5.0 to 5.1 to see if it’s any different to previous versions with regards to the update of the certificates.

To use CertGenUtil.exe you will need to create a short config XML file so that it will generate the SSL Certs Correctly. The following is an example:

<config>

<DR_CERT_SERVER>SRMSERVERIP</DR_CERT_SERVER>

<DR_CERT_ORG>YOURCO</DR_CERT_ORG>

<DR_CERT_ORG_UNIT>YOURORG</DR_CERT_ORG_UNIT>

</config>

Replace SRMSERVERIP with the IP Address of your SRM Server, YOURCO with your company and YOURORG with your OU. Save the config file in an easily accessible location on the server where you’ll install SRM 5.1, such as c:\ or c:\temp, in the example below I’ve saved the file as srm-certcfg.xml in c:\temp. Note: you only need to install SRM 5.1 to get the CertGenUtil.exe, you are not required to upgrade your environment to SRM 5.1. So it would pay to do this in a test environment with a SQL Express instance and a test VC.

By default the CertGentUtil.exe file is located in c:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

On a server installed with SRM 5.1 or that contains the SRM 5.1 CertGenUtil.exe file execute the following command:

c:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin\CertGenUtil.exe -cfg c:\temp\srm-certcfg.xml

You will notice this line appears immediately:

VMware internal use only. This program is intended for use only by the SRM installer.

Follow the on screen messages that are displayed.

Installing The New Self Signed SSL Certificates

After the certs are generated you need to install them in the trusted certs store of both SRM Server and also both of the vCenter Servers (Protected and Recovery Sites). This is as simple as logging into the systems as administrator coping the new Cert file across and double clicking it to install it in the cert store (Follow the wizard). You will need to go through SRM and do a ‘Modify’ install and use your new certs in .p12 format. You may need to restart the SRM Services on both SRM Servers before the new certificates will be loaded into memory.

Final Word

I hope this helps if you quickly need to regenerate the default self-signed SRM Certificates for 4.x and 5.x to be compliant with the new MS patch. I would recommend that you use CA signed certificates to improve security and reduce the risk of man in the middle attacks, so this should be viewed as a temporary measure. This should allow you to continue to run your existing systems till you are able to upgrade to SRM 5.1.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

While there are a total of 136 steps in the process to update the CA SSL Certificates in the Windows vCenter 5.1 there are only 81 steps to update it in the vSphere 5.1 vCenter Virtual Appliance. But note that these steps do not include update manager. I will include the link below to the KB regarding update manager also.

Here are the KB articles required to update the vSphere 5.1 vCenter Virtual Appliance and Update Manager.

Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 – http://kb.vmware.com/kb/2036744

Configuring CA signed SSL certificates for vSphere Update Manager in vCenter 5.1 - http://kb.vmware.com/kb/2037581

It was another great team effort across the globe within VMware to put these instructions together and test them. Hopefully you find this information useful.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

This work covers vCenter, and all the related core components such as SSO, Inventory Service, Update Manager etc. The great news is that this work has resulted in KB’s that I and a number of others have tested and verified to work with vSphere 5.1 GA for the Windows installable version of vCenter. There are also updates to some previously released KB’s for vSphere 5.0. These processes will also work with the recently released patches to vCenter. The KB articles for the vCenter Virtual Appliance edition will also be published shortly and I will update this article when they are available.

Below are the links to all of the articles and a note with regard to Update Manager. I want to say a massive thank you to all of the people at VMware that made this happen. It was a big team effort. I’m glad I could make a contribution to the effort.  I will be making sure the process is automated for you as part of the vCert Manager project that I’m working on. My goal would be to automate both the Windows Installable and Virtual Appliance editions for vSphere 5.1.

Note you should start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1.

VMware has also put out a blog article on these KB’s titled Implementing CA Signed SSL Certificates with vSphere 5.1.

Note: I have found a problem with Update Manager when vCenter system is an all in one configuration with everything on the same VM and using a local MS SQL Server database. Update Manager will not be able to log into or register with vCenter when the SSL certificates have been changed. This prevents you from updating the SSL certs for Update Manager and Update Manager may no longer work. This does not appear to occur when the MS SQL Server database is remote. I have not tested this with a local Oracle or other supported local database. I am continuing to work with VMware on this issue and will update this article when it is resolved. In the meantime I would recommend placing the databases for vCenter and it’s other core components on a separate VM, even in small environments.

Final Word

Although changing out the self-signed SSL Certificates is not simple, and is very time consuming to do manually, the above articles make it possible and give you a tested and verified process. I will be automating the processes to take this pain away as part of the vCert Manager project. In the meantime I would recommend you start with KB 2034833 – Implementing CA signed SSL certificates with vSphere 5.1 and work your way through the rest. I hope you get a lot of value out of these articles and the effort that the team has put in. As always your feedback is appreciated.

Derek Seaman has put together a great series of articles on VMware vCenter 5.1 Installation that includes coverage of SSL certificates. I would highly recommend you check it out. Derek has made a great contribution to the process for SSL Certificate Replacement in vSphere 5.1.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

vRAM and Cloud Suites: Ding Dong! The Witch is dead. Which old Witch? The vRAM Witch! (The movie this is from is well before my time – Can you guess which movie?) Yes the vRAM Witch is now definitively dead. VMware Announced in the first Keynote on Monday 27th August that vRAM licensing is no more and they will instead be introducing vCloud Suites containing a bundle of products based on per CPU Socket, unlimited cores, unlimited RAM, and unlimited VM entitlement per licensed socket. Although the suite is a collection of products right now over time will become ever more integrated, and the licenses can’t be broken apart into their individual components. This is all very good news for VMware customers. The vRAM announcement was made in the context of vSphere 5.1, but it also applies to vSphere 5. So even if you’re running a vSphere 5 environment vRAM is no longer relevant. Personally I didn’t have a problem with the concept of vRAM as everything is moving towards a consumption based model, but it did cause a lot of extra things to consider during design, especially when every customer I ever engaged with had no impact as a result of vRAM. The free VMware vSphere Hypervisor will still be limited to running on hosts with 32GB physical RAM, but there are no longer any vRAM limitations (think configured memory / overcommitment is unlimited). Everyone with vSphere Enterprise Plus will get entitlement to vCloud Suite Standard, and VMware will be running promotions to get customers to upgrade to the other editions, so watch out for those. Information and comparisons between the vCloud Suites. This is great news for all environments, especially those with Monster VM’s. So now you don’t have to worry about VMware vRAM licensing for your business critical applications you can go back to only worrying about your ISV licensing and the best solution to meet all your other requirements.

vSphere 5.1 and the Mega Monster VM: 64 vCPU, 1TB RAM, 1M IOPs per VM, less network jitter, lower latency, Zero-downtime upgrade for VMware Tools (from 5.1 onwards), Dump Collector works with vDS. These are just some of the highlights of vSphere 5.1. VMware has taken the Monster VM and turned it into a more Mega Monster VM. Best of all the efficiency is still what you come to expect form VMware. So if you can configure 64 vCPU’s you know you can get within a few percentage points of native. IMHO it’s not good saying your architecture supports a huge number of vCPU’s if you can’t utilize them efficiently. VMware does a lot of work to ensure they optimize their architecture to get best efficiency as well as scalability. 1 Million IOPS per VM is great if you have a single VM that you can run off an entire fully FLASH array. But realistically this is just to eliminate any possible thoughts that the hypervisor is the bottleneck when it comes to storage. The test was conducted with 4k IO size and produced very low latency. The IO Size and Latency being important factors as I outlined in Storage Sizing Considerations when Virtualizing Business Critical Applications.  See What’s New in VMware vSphere 5.1 – Platform and What’s New in VMware vSphere 5.1 – Performance.

VMware vSphere Distributed Switch: Config Backup/Restore, Rollback and Recovery, Network Healthcheck, BPDU Filter. There is now no reason to run a mixed vSS / vDS environment. With the config backup / restore and automatic rollback and recovery you can be confident that the vSphere Distributed Switch (note name change) will be reliable and available, and easy to recover when things go wrong. The Rollback and Recovery will revert any change that has the consequence of disconnecting the hosts from vCenter or vice versa. Network Healthcheck will periodically check the network for configuration errors such as incorrect VLAN trunking, incorrect MTU, uplink erros etc and alert you to these issues before they become a major problem. This should greatly reduce the effort required in quality assurance when provisioning new hosts and operating hosts as the environment changes. The new vDS also supports Netflow v10 (IPFIX), LACP (IP Hash Only), and also RSPAN/ERSPAN. BPDU Filter is important as it stops the accidental or malicious configuration of a bridged VM from causing a physical host port down event and cascading failure across the cluster. BPDU filter will filter out any BPDU packets. As mentioned above the Network Dump Collector, which collects Purple Screen of Death (PSOD) Core dumps from ESXi hosts now works with vDS. In vSphere 5 this only worked with the standard vSwitch. See What’s New in VMware vSphere 5.1 – Networking.

VMware vSphere Storage Enhancements: All Paths Down (APD), Permanent Device Loss (PDL), Storage IO Control Enhancements, Parallel Storage vMotion, Combined vMotion / Storage vMotion without Shared Disks. The APD and PDL behaviour has been again enhanced in vSphere 5.1, which will see far more predictable behaviour under what should be very rare storage failures. Storage IO Control has been enhanced to be more self tuning. Storage vMotion now supports up to 4 parallel disk copies per VM. See What’s New in VMware vSphere 5.1 – Storage. With the combined vMotion / Storage vMotion and no need to have shared storage we can say goodbye to the concept of a swing datastore or jump datastore. Duncan Epping does a great job of covering this in his article “Say Goodbye to the Transfer LUN aka Swing LUN aka Stepping Stone“.

vCloud Networking and Security: HA, SSL VPN, Load Balancer, 10 NIC’s per Edge, VXLAN Gateway, Endpoint included with vSphere 5.1. All of the new features of vCloud Networking and Security are a major leap forward from the previous version of vShield, which this supersedes. The HA functionality for vShield Edge combined with support for 10 NIC’s, which are user configurable between internal / external means that you can realistically replace a large number of enterprise firewalls very cost effectively. This also means you can very cheaply set up realistic testing and validation environments to test multi-tier applications and their firewall rules before you apply the firewall rules to production physical firewalls. With HA if one host with the primary Edge device fails the firewall state will failover to stand by Edge, this is a real active / passive firewall cluster. Load balancing has been greatly improved to include health checks and can now support HTTPS pass through and any custom TCP ports. SSL VPN is a very convenient way of allowing end user access to the vApps and infrastructure protected by the Edge or for management of the infrastructure. The admin user interface has been greatly enhanced and so has it’s capability, including the logging functionality. Many will be pleased that rules now have a rule ID and this flows through into syslogs. The interface is much more intuitive when it comes to App Firewall also and is simplified removing the rule precedence that existed in the previous version. Flow monitoring is improved and you can now get statistics per rule to determine which rules are being used in addition to the top rules that are used. With Endpoint now included with the Hypervisor I predict that most organizations will start moving to VMware’s Endpoint protection and partner integrated solutions. Service Insertion now allows parters to integrate virtual editions and physical editions of their components with vCloud Networking and Security and also vCloud Director. This will allow many organizations to further differenciate their services and offerings.  The automation capabilities that are possible through vCloud Director, vCloud Connector and the REST API’s mean that vCloud Networking and Security is a major step forward with capabilities that really deliver on the software defined datacenter and software defined networking and security. See VMware vCloud Networking and Security Overview.

vCloud Director: SDRS Integration, Storage Profiles / Storage Tiering, Elastic VDC, Linked clones on VMFS across 32 hosts, vApp Snapshots, HA Edge Devices. See What’s New in VMware vCloud Director 5.1. There are so many improvements in vCloud Director 5.1 that I’m only going to cover a few very briefly. Storage DRS and Storage Profile integration is a big one. You will no longer require a separate Provider VDC just to support a different tier of storage. For smaller environments this made the design very tricky as you might in a single 2 or 3 node cluster have to support 2 tiers of storage. This forced you to break with some best practices and use resource pools instead of clusters as the demarcation for the Provider VDC compute resources. This will help greatly improve resource utilisation efficiency in vCloud Director environments. It will be interesting to see the new designs incorporating this and how they are now differentiating their service offerings. With vCloud Director 1.5 you could configure an Elastic VDC across multiple clusters only with the PAYG resource model, but all the vShield Edge devices stayed in the original cluster. With 5.1 you can now do this also with the Allocation Pool resource model and vShield Edge and system resource pools will be split across clusters. With the addition of VXLAN it is now also easier to stretch VDC’s across clusters and this adds improved performance to the isolation networks.

New Certifications: VMware launched a number of new certifications for the Desktop and Cloud tracks. We now see certification paths right up to VCDX-Cloud and VCDX-Desktop. The existing VCP and VCDX have been renamed slightly to VCP-DV and VCDX-DV to designate Datacenter Virtualization. The actual path to VCDX-Cloud and VCDX-Desktop is not quite clear yet and neither is the migration path for existing VCDX qualified individuals. But it is great to see these two new certification paths that will allow everyone to demonstrate their mastery of these technology areas in addition to Datacenter Virtualization. See VMware Certification Roadmap. If you think this looks similar to how Cisco’s certification works you’re right. This is intentional and it just happens the man who designed Cisco’s certification tracks is now in charge of doing that at VMware.

Oracle Virtualization Architecture and Performance Deep Dive: I presented two sessions at VMworld US regarding Oracle Virtualization. The first one APP-BCA1432 – Virtualizing Oracle Across the World — Success Stories from University of Auckland and Indiana University covered the process of how to go about virtualizing Oracle when migrating from traditional Unix platforms and how to engage the DBA’s and keep them happy. My content was based on a large project that I had delivered on behalf of VMware Professional Services. I had Don Sullivan (Oracle Certified Master) from VMware and Dan Young from Indiana University as co-presenters. In my second session APP-BCA1624 Virtualizing Oracle: An Architectural and Performance Deep Dive we really drilled into how to architect Oracle databases for maximum performance and how the hypervisor helped. In this session I had Mark Achtemichuk from VMware (Performance Technical Marketing) and Don Sullivan again. I took the same project as my previous session but this time really drilled down in the technical details of how we delivered 5x performance improvement from the source systems and as such a high ROI. Both would give you a very good understanding of how you really can virtualize Oracle Databases in large organizations successfully and ensure you meet the business requirements and performance requirements.

I received some pretty good ratings (4.39 and 4.3 respectively) for these sessions so a big thank you to all of the people that attended these sessions. You all thought we hit the mark with the content. This is very encouraging and I’ll try and do even better next year if I get a session selected. Based on the feedback a lot of people thought the sessions weren’t long enough. We could have talked for a lot longer and gone a lot deeper. This is the challenge when the sessions are only 60 minutes.

Automating Security and Compliance with DR: I presented this session INF-SEC1282 Automating Security and Compliance with Disaster Recovery Using VCM, vCOps, vShield, VIN and SRM along side Gargi Keeling who is the Product Manager for Security at VMware. This presentation was loosely based on a customer project I had been involved with where we had designed automated security and compliance processes along with DR. In addition to the learning from the actual customer project we enhanced the presentation with a partner solution (Catbird) that allows for automated syncing of vShield polices across multiple datacenters. The presentation covers all of the process and technology steps you need to take and gave an example of a technical architecture that would allow you to implement this, all using out of the box functionality from vShield, vCenter Configuration Manager, vCenter Operations, Virtual Infrastructure Navigator, and vCenter Site Recovery Manager, and supplemented if required with the Catbird solution. This presentation was also the worldwide premier of the SSL Management Solution mentioned below vCert Manager, which was very well received.

I received pretty good rating for this session of 4.15. Not quite as good as my Oracle sessions, so I will try and do better next time. This one was pitched as just a technical session not advanced technical. I also received a lot of feedback that the session wasn’t long enough and it would have been good to have the time to go deeper. What I’ve learned from the presentations I gave is that I probably need to narrow the scope and go a lot deeper. This will allow a lot more to get into a 60 minute presentation. Feel free to comment on this article and let me know your thoughts on this.

SSL Management – vCert Manager: My demo of the vCert Manager prototype was very well received and everyone in the audience of the Automating Security and Compliance with DR session agreed it would greatly simplify the process of managing SSL Certificates in VMware environments. I have published the Demo online and written about it in article vCert Manager – Changing VMware SSL Certs Made Easy.

Top Sessions I Attended:

The below sessions I highly recommend you review. I attended these sessions and thought they were a real highlight. Note I only had very limited time so I wasn’t able to attend many great sessions. I would have liked to have gone to the vCenter Technical Deep Dive and also Jason Nash’s vSphere Distributed Switch Deep Dive also. Jason got the top session of VMworld this year. I think it might be the first year a non-VMware employee has had the top spot.

Virtualizing SQL 2012: APP-BCA1516 Virtualizing SQL 2012 : Doing It Right. Jeff Szastak of VMware and Michael Corey of Ntirety managed to get through 160 slides of a very entertaining and deep technical presentation in just 60 minutes. I think they finished on time to the minute even with questions. I was very flattered that Jeff and Michael borrowed a quote from my Oracle Virtualization Architecture and Performance Deep Dive – “Your database is just an extension of your storage”. It is definitely relevant to SQL just as it is to Oracle or any other database. Optimizing storage performance is critically important and Jeff and Michael covered it well in the context of SQL Server 2012 and the relevant best practices.

SMP FT a.k.a. Multi-vCPU Fault Tolerance: INF-BCO2655 VMware vSphere Fault Tolerance for Multiprocessor Virtual Machines—Technical Preview and Best Practices. Presented by Jim Chow, Shrinand Javadekar, Srinivas Kotamraju, all from VMware. There was no timeframe or commitment given on when or if this might actually make it into the product given given how good it was I really hope it’s sooner rather than later. One of the attendees said this technology would literally save peoples lives as he worked in the 911 system as a systems admin and they could not leverage VMware FT currently due to it’s limitations. I can see many and varied applications for this. I can’t wait to get it into my lab environment when if it gets released.

Stretched Metro Clusters: INF-BCO1159 Architecting and Operating a VMware vSphere Metro Storage Cluster. Duncan Epping and Lee Dilworth did a great job of covering all the key points of architecting and operating a vSphere Metro Cluster environment. This is becoming a very popular solution for many environments these days, but it is not without its challenges.

Storage DRS Datastore Clusters: INF-STO1545 Architecting Storage DRS Datastore Clusters. Frank Denneman and Valentin Hamburger highlighted a number of key considerations when architecting Storage DRS datastore clusters, including some important limitations and considerations around storage IO control and array auto tiering. I wouldn’t operate a Storage DRS Datastore Cluster environment without reviewing this session first.

Oracle RAC Cluster Build Automation: APP-BCA1333 Virtualizing Oracle RAC. Rick Lindberg, Don Sullivan and Bryan Wood of VMware took the audience through the ins and outs of successfully virtualizing Oracle RAC on vSphere. Including the fully automated deployment of a new Oracle RAC Cluster in under 30 minutes (cut down demo recording was 7 minutes). The automation, which is available via a VMware Professional Services engagement allows not only new Oracle RAC Cluster creation but also node addition and node removal from existing clusters that have been created through this process. This will be especially valuable in Test and Development environments. The session also covered what VMware IT is doing in the process of virtualizing all their Oracle RAC systems and the necessary best practices to ensure the process is successful.

Final Word

It was great to see Oracle actually had an official presence at VMworld this year. They had a booth in the Solutions Exchange, which I stopped by for a chat and they gave me a nice T-shirt, and also had taxis and branded cars taking customers from their hotels to VMworld. This is another great show of support for VMware, which is a great place to run Oracle databases and applications. Oracle also confirmed at VMworld that running their applications and databases in a large cluster and using DRS Must Affinity Rules is a perfectly acceptable solution, provided the rules are not violated and the Oracle software is not installed and/or run on an unlicensed host. They also completely clarified the support situation with VMware vSphere. I think all of this is absolutely great news for Oracle and VMware customers. Now if you don’t believe that this actually happend why not just review the video, which is in an article on the License Consulting blog - VMworld TV – Richard Garsthagen Oracle Licensing and Support in VMware Virtualized Environments.

This was my first ever VMworld and it will definitely not be my last. I had a great time presenting to over 650 people and got great feedback. I met so many great people and was able to hang out with some of the VMware virtualization royalty. The only problem I had with VMworld was that it went way too fast. Mind you it was really hard work getting up at 6am every day and not getting to bed until after midnight most days. I would like to once again thank everyone that attended my sessions and gave feedback through the surveys, it was greatly appreciated. I’m looking forward to seeing some of the great people again in a couple of weeks at VMworld Barcelona, which I will be presenting a session titled APP-BCA1751 – Oracle Virtualization: Caging the Licensing Dragon with a great lineup of co-presenters. I hope to see some of you there. I also hope to meet a lot more new people.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Before we go into the guide and my take on some of the new aspects I want to make you aware of a recent announcement that vSphere 5 has achieved Common Criteria EAL4+ Certification. This is an important benchmark and milestone for vSphere 5. This gives assurance that vSphere 5 can be configured in a secure manner and the security functionality is effective as per the software design. This is particularly important for hypervisors that will run multiple Guest OS instances on them, as they must ensure the isolation and security is enforced as designed.

The hardening guide is now delivered in a spreadsheet which is much easier to use and include in other documents. It’s very easy to follow, sort and search.

vSphere 5 Hardening Guide Official Release

VMware Official Announcement – vSphere 5 Hardening Guide Released

I previously wrote about some of the important changes in the new hardening guide vs the vSphere 4.1 hardening guide in my article vSphere 5 Security Hardening Guide – Public Draft. I would encourage you to review that article if you haven’t already as the points are still very valid. Since that post there have been some additional changes made to the hardening guide to include my recommendations around SSL certificates in particular, as well as clarification around some of the options that impact functionality.

I would like to draw your attention to the vCenter SSL Certificate recommendations in particular. Additional recommendations are made to check the validity of certificates and also to remove any expired or revoked certificates from your environment. These are very important administrative tasks that should be done if you are using custom SSL certs in place of the default self-signed certs. In my previous post I have linked to William Lam’s blogthat contains scripts to help you automate this task. If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy.

William has also updated his vSphere 5 Hardening Guide Script, which will check the options against the guide and also check your certificates. You can find William’s script at the following location:

virtuallyGhetto: vSphere Security Hardening Report Script for vSphere 5

One of the reasons this is so important is that it protects you from possible man in the middle (MiTM) attacks. Another reason is because vCenter and the vSphere Client does not programatically check the validity of a certificate that it already trusts. It is once trusted, always trusted, unless you remove the trust. Without these important administrative tasks vCenter and the vSphere Client will continue to allow access without warning to any component with a previously trusted yet expired or revoked certificate. However any component that leverages Internet Explorer (such as performance overview and many of the vCenter plug-ins) will start to display warnings or cease to function if the certificates expire or are revoked, this is due to the checks that Internet Explorer does on the SSL certificates.

By considering security in your architecture design, making your designs secure by default and taking into account the appropriate level of hardening from the vSphere 5 Hardening guide you will have the best possible chance of limiting any security risks in your environment. Every environment has security risks, it is up to you as the administrator or architect to ensure you have the appropriate configuration, tools, controls and processes in place to limit the risks and balance security with functionality.

Now that we have the official vSphere 5 Hardening Guide I’m sure we will shortly see the vSphere 5 Hardening Template for vCenter Configuration Manager (vCM). If you don’t already have vCM as part of vCenter Operations Manager Suite – Enterprise I would strongly encourage you to purchase vCenter Operations Enterprise (include Operations, Capacity Planning, Virtual Infrastructure Navigator, vCenter Chargeback and vCM), or purchase vCM separately, or at least try it out in a proof of concept implementation. It will allow you to automate your security hardening and reporting across your vSphere Environment, as well as giving you visibility of configuration drift. vCM isn’t just limited to vSphere environments though as it supports native OS and physical systems (Traditional Unix, Linux and Windows). It can provide a one stop hardening, change management, compliance and audit/reporting shop for your environment, or at least the important parts of it. As well as physical bare metal OS provisioning and OS patching.

I hope you get a lot out of the hardening guide a lot of people at VMware have spent probably thousands of man hours compiling it and testing the recommendations and many of us interested parties have provided feedback to try and make this guide as good as it can be. Let me know what you think about the new hardening guide, I’m always keen to get your comments.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I think you’ll really like the new format. It’s now delivered in a spreadsheet which is much easier to use and include in other documents. I would encourage you to review the drafts and to provide feedback directly to VMware via the community threads linked below, where you can also download the hardening guide.

vSphere Hardening Guide: 4.1 and 5.0 comparison – Rev B

vSphere 5.0 Hardening Guide – Public Draft

Duncan Epping has also published an article on the release of the public draft available on Yellow-Bricks - vSphere 5.0 Hardening Guide public draft available.

William Lam has just updated his vSphere Security Hardening Script and it is available in his article vSphere Security Hardening Report Script for vSphere 5.

One of the most important changes in my opinion is the removal of the recommendation to disable the VIX API from each VM in the VM configuration. This change has been replaced by controls being recommended in vCenter Server that prevent unauthorized administrators from making use of the API, while still allowing it’s functionality where necessary. This is a good change that balances functionality with security, and I’m very pleased to see it.

You may remember that I recently commented about the VIX API impact on SRM in my article – vSphere Security Hardening Policy and SRM 5, and this was also picked up on by Tech Target in VMware SRM 5 encounters potential security conundrum. There is now no longer a conflict or conundrum between the hardening guide and the requirements for SRM to re-IP VM’s during recovery. The use of the VIX API can be restricted to the SRM Service Account only, so that only this account, and not any human interactions (except for the supreme Administrator) can call it.  It can further be restricted to only the VM’s that require SRM to change their IP’s during recovery, by choosing where to apply the permissions. This makes it very easy to audit.

I was fortunate to be able to provide input into parts of the hardening guide while in ‘beta’ effectively, and I will be providing further feedback on the public draft. From my perspective I think it should include more recommendations regarding SSL certificates. I think SSL Certs, given the importance and difficulty, needs a bit more of a mention, especially around expiry and validity checking.

William Lam at virtuallyGhetto has written a couple of very useful blogs on the topic of SSL Certificates that you may like to review. I hope that the recommendation to check expiry makes it into the final version of the hardening guide. If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy.

Extracting SSL Thumbprint from ESXi – virtuallyGhetto

Automating SSL Certificate Expiry Validation for vCenter Server + ESX(i) Hosts – virtuallyGhetto

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

The first place you should go when trying to update SSL Certificates in any of the VMware products is the product documentation. At least for an overview of how the process might work. As you are probably aware by now (If you’ve read my previous posts on the SSL Cert Topic – Updating CA SSL Certs in vSphere 5)  there have been a number of examples where the documentation isn’t quite complete or easy to follow. This is also the case with the vShield 5.0 Admin Guide. This article will outline the steps necessary to update the SSL Certs on vShield Manager 5.0 and give you an insight into some of the differences with 5.0.1 that we discovered along the way.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

Prerequisites and Assumptions

This article assumes you the following:

• You already have an Organisational CA and PKI Infrastructure.
• vShield Manager is already deployed in the environment with configured with a valid IP address on the management network.
• You have validated connectivity to your vShield Manager prior to executing this process.
• Your vShield Manager must have a fully qualified domain name in your DNS.
• If you are using a Windows 2003 CA you have applied Microsoft KB 931351 to allow the SAN attribute to be specified as part of the certificate request. This will require a restart of the CA services.
• Your CA certificate template supports the Subject Alternative Name (SAN) attribute in certificate requests. Your chosen CA Certificate Template should be verified before you start this process.
• You have a copy of your Root CA and Intermediate CA (if applicable) Certificates available for use during this process.
• You are using Internet Explorer as your browser. Note: Other browsers will work for some parts of this process, however they may not work with the CA certsrv web site and root certificates may need to be pre-trusted in the non-IE browsers.

You will be required to log in as admin to perform all the tasks outlined and will require access to the CA to request and download the certificate.

Updating SSL Certificate in vShield Manager 5.0 High Level Steps

Here I will give you an overview of the high level process steps and then dig into the detail including screenshots in the next section. I hope this makes your process of updating the vShield Manager SSL Certs as painless as possible. This process was tested using vShield 5.0 and 5.0.1 and a Windows 2003 CA, but will also work with Windows 2008 and above.

1. Generate the Certificate Signing Request (CSR) from the vShield Manager SSL Certificates GUI with the correct details for your organization and CA.
2. Download the generated CSR from vShield Manager and Submit it to your CA.
3. Download the CA signed SSL Certificate generated in Step 2.
4. Download or export the Root CA Certificate and Intermediate CA Certificate if applicable.
5. Import the Root CA Certificate to vShield Manager.
6. Import the Intermedia CA Certificate to vShield Manager (if applicable).
7. Import the CA signed x.509 SSL Certificate for vShield Manager.
8. When the new CA signed SSL Certificate in Step 7 is applied the vShield Manager will reboot, when this is complete log back into vShield Manager.

So only 8 steps, seems easy right? Well it is fairly easy, but there are some catches, which I’ll explain in detail below.

Updating SSL Certificate in vShield Manager 5.0 Detailed Steps

Now we will dive into the detailed steps required to update the SSL Certificates for vShield Manager. As I take you through this I will point out the gotcha’s and inconsistencies with the existing product documentation you need to be aware of as we come to the relevant steps. Screenshots are included to make the process easier to follow. Bare in mind as you are going through this process that vShield Manager is registered with vCenter using it’s IP address and accessed from within vCenter Server using your browser. This is an important aspect when it comes to certificates and validity checks.

1. Log into vShield Manager as admin.
2. Click Settings and Reports in the left hand navigation window.
3. Click SSL Certificate.
4. You will find yourself presented with a form allowing you to enter the information required to generate a Certificate Signing Request (CSR). I suggest using RSA 2048bit key. At this point you need to use the fully qualified domain name (FQDN) of the vShield Manager as the Common Name. Failure to use the FQDN will result in an error in vShield Manager 5.0 and you will not be able to generate the CSR. This is the first inconsistency with the product documentation as it advises you to use the IP address of the vShield Manager, which doesn’t work. Using the IP address as the Common Name is possible in vShield Manager 5.0.1.  Fill in the CSR information similar to the following image with your relevant organization details.
   
5. Click the Generate Button.
6. When the CSR is generated you should see a message displayed in a yellow bar at the top of the screen saying “Certificate Signing Request is generated successfully”, Click the Download generated certificate link on the right hand side of the screen. Save the file somewhere easily accessible.
7. Submit the CSR to your CA using either the certreq command or the certsrv web site on your CA. The step-by-step instructions for using the certsrv web site are as follows:
   • Browse to http:// or https:// <yourca>/certsrv from a supported Guest OS and a supported browser (refer to Microsoft for this information for your specific CA).
   • Click Request a certificate Link.
   • Click advanced certificate request Link.
   • Click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file. Link.
   • Copy and paste the text from your CSR into the base-64-encoded certificate request box, making sure to remove any erroneous carriage returns, select the correct certificate template, and enter the SAN information in the Additional Attributes Field (similar format to the diagram below).
   • Click Submit button.
   • Click Base 64 encoded radio button and click Download certificate, save the certificate in an easily accessible location.
8. Be sure that you specify the Subject Alternative Name (SAN) of your vShield Manager using it’s IP address as an additional attribute during your request. If you fail to specify the IP address in the SAN you will be prompted with a warning dialog each time you access vShield Manager via vCenter Server. This is because vShield is registered with vCenter Server and accessed using it’s IP address and the IP address won’t match the Common Name specified in the certificate. To specify the SAN use the additional attribute SAN:dns=xxx.xxx.xxx.xxx, where the x’s are replaced with your vShield Manager IP address, as shown in the example image.
   
9. Open your newly generated certificate and verify the attributes are as you expect and the Subject Alternative Name is correctly showing the IP address of your vShield Manager.
10. In vShield Manager on the SSL Certificate Tab ensure Import Signed Certificate is expanded and visible. At this point the Product Documentation advises you to import your CA signed certificate, however this will not work. If you attempt this you will see a message displayed saying that importing the certificate failed. This is because you have not yet imported the Root CA certificate or Intermediate CA certificate (if applicable).
11. Select Certificate Type Root CA. You will see something similar to the following displayed.
    
12. Browse and find your Root CA certificate and use that as the Certificate File, then click Apply button. A yellow bar containing the message “Successfully imported certificate.” should be displayed at the top of the screen.
13. If you used an Intermediate CA to generate your certificate then repeat steps 9 and 10 for the Intermediate CA certificate as the Certificate File being sure to select Intermediate CA for the Certificate Type as per the image below.
    
14. Repeat steps 9 and 10 and using the CA-signed X.509 Cert as the Certificate Type and using your CA signed vShield Manager certificate for the Certificate File, similar to the image below.
    
15. When the certificate is imported successfully you will see an Apply Signed Certificate box at the top of the screen. Click Apply Certificate. If you see an error displayed in the yellow box stating “Error: Importing certificate failed. Please retry the operation” either the root or intermediate CA certificates are missing or not imported correctly, or there is a problem with your CA certificate. You may have to start the process again. You may with to refer to VMware KB 1035387 – Importing SSL certificates in vShield Manager.
16. vShield Manger will be restarted to apply the certificate, once it has restarted, log in again as admin by accessing vShield Manager using it’s IP address. You should not be prompted or warned that you are accessing an untrusted site and the vShield Manager login screen should be immediately visible. To verify the certificate click the padlock icon in the address bar.
17. Congratulations you have now completed the update of your vShield Manager SSL Certificate Successfully!

Please Note: I have received reports that the SSL Certificate is lost when an upgrade from vShield Manager 5.0 to 5.0.1 is performed. I have not yet been able to verify this with VMware or tested it myself. I would suggest that a backup of vShield Manager is taken prior to any upgrade process. I will investigate these reports and update this post. I would like to hear from you if you have experienced this yourself, or if you have any feedback on this process.

Big thanks to Maish for being the inspiration for this article and for help with some of the detail included in this article.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. This will remove the chances of making most of the top 5 mistakes listed below. 

Top 5 Common Mistakes when Implementing CA Signed SSL Certs in vSphere:

1. Not following the correct procedure or steps, or missing out a step
2. Missing attributes from a Certificate Signing Request
3. CA Certificate Templates not configured correctly
4. Not using text transfer mode when copying cert files to ESX/Linux systems
5. Not having the full CA key chain in the certificate

Not following the correct procedure or steps, or missing out a step

For this you could be forgiven. The vSphere documentation is not complete and is not easy to follow. The multitude of KB’s are also not complete and not always easy to follow. After the attention I’ve bought to this topic improvements are being made and it will be a lot better in the future. There are a lot of detailed steps that need to be followed. Even my blog posts on this topic (which have now been tested quite a few times) have gone into a lot of detail. One missed step or incorrect step can cause the entire operation to fail. So best not try and do this during a period where you’re sleep deprived. The best advice here is to follow the steps in my blog articles (Refer to the posts listed Updating CA SSL Certificates in vSphere 5) carefully and watch out for updated VMware documentation and KB articles. Always have a backup of previous certs and always try updating certs in a test environment before doing it in production. Make sure when you are requesting and generating your certificates that you select the correct template. You need to use a template is based on the standard Web Server (Assumes Windows CA). Make sure the password in the PFX file is ‘testpassword’ and make sure the certificates are downloaded in PEM base-64 encoded format. 

Missing attributes from a Certificate Signing Request and CA Certificate Templates not configured correctly

Common Mistake 2 and 3 can generally be combined into one area as they are generally around missing attributes or incorrect configuration

For the Certificate Signing Request and the CA Certificate Template they should have the following:

keyUsage             = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment # digitalSignature, keyEncipherment,  dataEncipherment are Mandatory, nonRepudiation Optional
extendedKeyUsage         = serverAuth, clientAuth # Mandatory
subjectAltName        = DNS:updmgr.homedns.org, DNS:updmgr # Optional, except with SRM

Make sure that you’re Windows CA Certificate template has the option “Allow Key Exchange Only With Key Encryption” selected in its key usage policy. It will not work without this.

You need to verify your certificates when you get them back from your CA to ensure that they include the correct fields and that all fields are populated correctly. The above are in addition to the normal request fields that are necessary for the CSR. You’ll find more information on my previous posts. Refer to the posts listed Updating CA SSL Certificates in vSphere 5 especially regarding vCenter.

Not using text transfer mode when copying cert files to ESX/Linux systems

This is probably one of the biggest catches when updating SSL Certificates, especially when they are generated in a Windows system and then copied to an ESX/ESXi or Linux system. The ASCII text file formats are a little different. If you don’t use text mode file transfer in WinSCP or other secure copy tools you will find additional unwanted characters in your certificate files. This will corrupt the file and render it useless unless corrected. Fortunately this is very easy to correct. Either copy the files again using text mode file transfer, or alternatively follow the process outlined by Maish Saidel-Keesing in his recent post Removing ^M Characters from Files in ESXi at TechnoDrone.

Not having the full CA key chain in the certificate

This common mistake comes thanks to Erik Bussink. It could sort of be covered by option 1 but happens frequently enough to have a separate item.  To ensure you don’t run into this make sure you download the full base-64 encoded certificate from your CA that includes the full key chain. In a Windows CA this is as simple as just downloading the base64 encoded certificate on the final page of the certificate submission workflow. This may also require importing the trusted Root Public Cert using openssl or Java keytool from the command line.

Hopefully by taking the above common mistakes into account, and by following the detailed articles I have posted on the topic you will find changing SSL certs in vSphere  much easier and more successful.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Firstly I’d like to start by saying this is what I’ve found the easiest in the environments I’ve worked in. Your mileage may vary. I have tested this with vSphere 5, but it may also be applicable for earlier versions. I’d like to hear from you on your experience and if this has worked for you, or if you used a different order.

1. ESXi Hosts
2. vCenter Server
3. vSphere Web Client
4. Other Components, such as SRM, vCenter Operations Manger, VMware View, vShield etc

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

The reason I have found that this order is the easiest is because if you update the ESXi Hosts certs first with trusted CA certs they can be added into vCenter quicker. The hosts will also not become disconnected and require you to reconnect them when you change the vCenter SSL certificates. The reason why I have the vSphere Web Client listed before other components is because it will generally be installed on the same server as vCenter Server. Unless of course you have a very large number of vSphere Web Client users, which which case you will have split it out onto a separate server.

If you can update the SSL Certs on the ESXi Hosts before adding them into vCenter it will save you some time as you won’t have to fix the SSL thumbprints in the vCenter Database, which is due to be fixed in vSphere 5 Update 1  (refer to The Trouble with CA SSL Certificates and ESXi 5).

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Long White Virtual Clouds Articles on CA SSL Certificates

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

This list below contains links to all of the relevant articles I have posted regarding changing SSL certificates in vSphere 5 and related products. Each link will open in a new window. I have tested the processes outlined in these articles and verified them with customers. This work is being used to update the VMware KB articles.

Updating CA SSL Certificates in vSphere 5.1

Updating CA SSL Certificates in vSphere 5.1 vCenter Virtual Appliance

Changing vCenter Heartbeat to CA SSL Certificates

Updating SSL Certificate in vShield Manager Made Easy

Common Mistakes Implementing CA Signed SSL Certs in vSphere

Best Order for Changing SSL Certs in vSphere Environments

Why change VMware default self-signed SSL Certs?

Virtual Infrastructure Navigator breaks when vCenter SSL Cert Changed

vCenter Server Virtual Appliance – Changing SSL Certs Made Easy

vSphere Web Client SSL Cert not updated after vCenter SSL Cert Changed

The Trouble with CA SSL Certificates and vCenter 5

The Trouble with CA SSL Certificates and ESXi 5

If you have trouble following any of the above articles or you have a request with regard to changing SSL certificates in another VMware product please get in touch via the feedback form on the Author Page. As always your feedback and comments are greatly appreciated. There are still traps that might run into as PKI and SSL Cert generation is particularly complex. So do contact me if you are having a problem with any of the instructions. .

VMware KB Articles that have been or will be updated

In addition to the KB’s below a new general KB article with regard to changing SSL certificates in vSphere 5 will be published. This KB will bring together the relevant steps and will hopefully cover the full VMware Cloud Infrastructure Management (CIM) suite. As I become aware of new or updated articles I will include them here. So check back regularly to monitor progress.

Thanks to the great work of the VMware team for getting these articles created and updated.

VMware KB 2015387 -  Configuring OpenSSL for installation and configuration of CA signed certificates in vSphere environments – Created based on my work
VMware KB 2015421 – Configuring CA Signed certificates for vCenter 5.0 – Created based on my work
VMware KB 2015499 – Configuring CA Signed certificates for ESXi 5.0 – Created based on my work
VMware KB 2009857 – Certificate warning is reported even after replacing vCenter Server 5.0 default SSL certificates with custom SSL certificates – Updated based on my work
VMware KB 1023011 – Replacing SSL certificates for VMware vCenter Update Manager by using the Update Manager Utility
VMware KB 2007824 – After upgrading to vCenter Server 5.0, the vCenter Service Stats and Hardware Status tab cannot be accessed
VMware KB 1013472 – vCenter Server Service Status plug-in cannot be enabled

Other CA SSL Certificate Resources for vSphere 5

Generating SSL Certificates for vCenter Operations Manager 5.0 – Erik Bussink

vCenter Operations 5.x vCenter Plugin uses IP instead of DNS hostname – Josh Perkins

Creating a Certificate with Multiple Hostnames – Greg Rowe

vSphere 5 Certificates – Replacing the Default vCenter 5 Server Certificate – Julian Wood

vSphere 5 Certificates – Replacing the Default Update Manager Server Certificate – Julian Wood

Import an OpenSSL CSR into a Windows CA – Christopher Bean

Replace SSL Certificates: Replace vCenter SSL Certificates - Rynardt Spies

Replacing vCenter 4.1 SSL Certificate with Active Directory Issued One – Gavin Adams

Replacing vCenter SSL Certificate with Certificate Issued by Microsoft Certificate Authority – Josh Perkins

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

The default location for the vSphere Web Client certificates is C:\Program Files\VMware\Infrastructure\vSphere Web Client\DMServer\config\ssl. You will need to restart the vSphere Web Client, or reboot the vCenter Server to load the new certificates into memory. You will then be able to log into the vSphere Web Client to test that it is still functioning.

Updated: In most cases you should use the default keystore password of testpassword for your pfx file. If you chose to use a custom password for your keystore you will need to update the tomcat configuration files with the new password. Please refer to VMware KB 1013472 – vCenter Server Service Status plug-in cannot be enabled. However this doesn’t offer any additional security as the keystore password is still stored in clear text in these configuration files either way. Access to the filesystem locations of the important certificate and configuration files should be locked down to prevent any unauthorized access. Thanks to Dan Corrigan for raising this in the comments below.

You may notice that when you change the vCenter SSL Certificate that vSphere Web Client will pop up a warning box the when you attempt to log in. The warning box will say that secure communication can’t be verified. This is due to the thumbprint of the vCenter Server SSL Certificate being different to what vSphere Web Client recognized when it was registered with vCenter. If you click install the certificate and ignore to continue it will not prompt you again on this system. You will need to unregister the vCenter system on the vSphere Web client using the admin-app url, and then re-register it again. To do this you will need to log into the vSphere Web Client system using RDP (Assumes Windows Version), then opening https://localhost:9443/admin-app in a web browser. Once the vCenter System is registered with the new thumbprint the warning dialog box should not be displayed again.

WARNING: Under normal circumstances you should not blindly ignore these types of warning messages and should not automatically just install certs and ignore to continue. You need to institutionalize Standard Operating Procedures that question every time a warning dialog such as this is present and you must verify the authenticity of the certificate. Here is an example of the warning box with the vCenter Server and SHA1 thumbprint obscured.

So you don’t have to jump back to my previous article just to find the default location for the Inventory Service SSL Certs it is C:\Program Files\VMware\Infrastructure\Inventory Service\ssl.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.