While working on a recent engagement I had a discussion with a customer’s Architect about how we would issue certificates for a vSphere, vRA & vROPS deployment. The customer had no internal CA and relied instead on a public CA to issue all certificates that would be user facing.
This simplified the management of the certificates and meant they did not need to maintain an internal PKI infrastructure or root certificates on client devices. I explained to him that while this worked currently for their servers which used internal names or reserved private IPs it would soon change and they would need to look at deploying their own PKI infrastructure.
As of the 1st November 2015, public Certificate Authorities like Symantec and GlobalSign will no longer issue certificates with a subjectAltName extension or Subject commonName field containing a IP address within the IPv4 RFC 1918 reserved address space or IPv6 address in the RFC 4193 range:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
FC00::/7 prefix on an IPv6 address
This is also the case for Internal Names. An Internal Name is a Common Name (CN) or Subject Alternative Name (SAN) field of a certificate does not end with a valid Top Level Domain (TLD) i.e. .local, .internal etc. CN or SANs which end with valid TLD i.e. .com or .net will still be valid.
This will also affect certificates which use NetBIOS names or short hostnames i.e vCenter01, WebServer, Beeblebrox etc.
Any certificate which expires after the 1st November 2015 will not be reissued and after the 1st October 2016 all certificates which are still valid will be revoked by the issue CAs and will no longer work as a valid certificate.
This is not just a VMware issue and will impact all servers using certificates described above. However, if you are affected by this issue in your VMware environment, VMware have posted a KB article which covers the issue here.
VMware have released ESXi 6.0 Update 1a which fixes the issues noted in KB2124669 – ESXi 6.0 network connectivity is lost with NETDEV WATCHDOG timeouts in the vmkernel.log.
The update is available here.
Also, VMware have released ESXi 5.5 Update 3a which incorporates the patch for KB2133118 where Snapshot Consolidation caused Virtual Machines to crash.
Update 3a is available here
Hopefully vendors will released updated custom ISOs for both ESXi 5.5 U3a and 6.0 U1a over the next few days.
—-UPDATED POST FOR AUGUST 2016 vEXPERTS HERE—–
Earlier tonight I noticed a tweet from Zach Milleson (twitter) who asked if there was a #slack channel for vRO or vRA which got me thinking. We’ve just started to use #slack internally at Xtravirt and it’s had a great uptake and has increased the amount of collaboration within the professional services teams as well as given other teams opportunity to get help with issues when needed.
Having seen the impact #slack can have and with Zach’s tweet in mind, I’ve set up a #slack team for vExperts- https://vexpert.slack.com. The idea being that vExperts can use the various channels to communicate and collaborate across common topics.
It’s only using the basic package for now until I see how much usage we get. With this in mind it’s set to be invite only so if you want access please send a DM or tweet to “vExpert_slack” and I will add you to the team. I’ve created channels for things like vRA, VRO, VCIX and VCDX and can add additional channels if requested. It will probably take a little time to reach critical mass and as more people join the more useful it will become.
I’m currently working on a project for VMware Professional Services in Schiphol-Rijk, The Netherlands along with Marco van Baggum (twitter/blog). While testing the deployment of vRO my colleague and I noticed that we were getting errors when using certain browsers.
This error hadn’t occurred previously and nothing had changed with the SSL certificates. After a bit of head scratching I noticed that Chrome had recently updated to Version 45 (also disabling Java!) and was now blocking access to sites with weak ephemeral Diffie-Hellman keys. This is also the case for Firefox v40 and above but I’ve not come across the issue with Internet Explorer 11.
After some research I found VMware KB (link) which pointed me in the right direction.
vRO 6.x has the following keys enabled by default:
This includes the weak ephemeral Diffie-Hellman keys:
SSH to the vRO appliance, and edit the file /etc/vco/app-server/server.xml
Search for the line :
Remove the weak ciphers so the line is now:
Repeat the above for the file /var/lib/vco/configuration/conf/server.xml
Save the files and reboot the appliance.
When you access the vRO URL you should now see the following:
Late yesterday evening (UK time) while I was working away in the Netherlands, the 2015 Second Half vExperts was announced (VMTN Blog). This is the first year I have felt I’ve done enough to qualify so was amazed to see that I had been named along with my colleague Giuliano Bertello (blog.bertello.org / ). This now takes the number of vExpert’s at Xtravirt upto 13 (Jason Meers having moved on during the last 6 months).
So what is a vExpert? VMware vExpert is an honorary title VMware grant to outstanding advocates of the company’s products. A “vExpert” is not a technical certification or even a general measure of VMware expertise. The judges select people who are particularly engaged with their community and who have developed a substantial personal platform of influence in those communities. There were a lot of smart, accomplished people, even VCDXs, that weren’t named as vExperts this year. This accreditation means that the person is at the top of their game as well as an evangelist for VMware’s products.
To be included in this list of people is a huge honour and something I will work hard over the next 12 months to make sure I continue to justify my nomination,
Over the past couple of months I’ve been working for VMware Northern EMEA PSO via a partner on a project based out in Amsterdam. It’s been a great experience and I’ve really enjoyed the work. Unfortunately the project was stood down which meant the role was quite short lived. I met some great people out there and I’ve learnt a lot. One thing it has shown me is that I’m actually a lot closer to submitting a design for VCDX that I thought and it’s really pushed me to get going.
Since I finished in Amsterdam I’ve been looking at how I want to take my career forwards and how I can work towards the goal of achieving my VCDX. I’ve been working as an Technical Architect for a number of years but only recently in a role that was dedicated to VMware, which has meant I’ve built up a good knowledge across a number of technologies including VMware, Microsoft and Citrix. I wanted an opportunity where I could focus on VMware technologies but also not waste my experience in other areas. I’ve had a couple of conversations of the last couple of weeks with the guys at Xtravirt and I’ve been really impressed with their passion, knowledge and how they work. I’ve known a few Xtravirt employees though VMUGs, Twitter etc. and they have always had an excellent reputation as a company both inside and outside of VMware.
After meeting their CFO & Practise Manager and conversations with their CTO, I’ve accepted an offer for the role of Senior Consultant and will be joining this week. I’m hugely excited about the opportunity and can’t wait to get started. It’s going to be a great challenge and is just what I need to push myself forwards and towards the goal of achieving my VCDX and continue to develop my career.
I’m going to use this blog going forwards as a resource for others and will post as much as I can about the technologies I’ll be using, the challenges I face and my progress towards the VCDX.
I’d like to say thanks to Mike Jones and Gregg Robertson who have been great and huge help and support over the last couple of weeks as I’ve gone through this process.