After the domain controllers were upgrades to Windows [...]]]> The Problem

A client makes extensive use of the The Cisco Network Access Control (NAC), a.k.a. Clean Access solution for their wi-fi enabled laptops. These systems are Active Directory domain members and prior to an AD upgrade, would boot and have a user logged in within 2-3 minutes.

After the domain controllers were upgrades to Windows 2008 R2, the bootup process went from 2-3 minutes to 10-20 minutes, with the delays showing up on the “applying computer settings” and “applying user settings” notices (Windows XP clients). Event logs would show errors indicating DNS resolution had failed and similar things.

The Solution

By default, the configuration for the Client Access Server (CAS) has a set of default traffic filters to allow untrusted clients just enough access to the domain controller. This would be the typical ports you’d expect, such at 88 (Kerberos), 135, 137-139, 389/636 (LDAP/LDAPS), etc. These rules are also mentioned in various Cisco technical guides for example, in this one, or from the 4.1 Install guide.

What I noticed was that the high TCP ports, 1025 and 1026, reflect the Windows 2003 start of the RPC port mapper range (1025-5000). In Windows 2008 (and R2), Microsoft changed this to the TCP port range of 49152 – 65535. After changing the filter from something like this:

to this:

things started working as expected with laptops booting, apply settings, and allowing a user to login within 2-3 minutes. The port range can be tied down even further by configuring registry settings on the domain controllers, as mentioned in this article: Restricting Active Directory replication traffic and client RPC traffic to a specific port.

Only after the user logs in does the Clean Access Agent pop up and allow the user to authenticate using the AD SSO, and thereby moving them from the untrusted to trusted VLAN.

I didn’t see any mention of the need for the port range for the RPC end-point mapper, so did this as a hopefully helpful tech tip.

A quick Google search for “web [...]]]> SSL server certificates are mandatory for finance, e-commerce, and any site that wishes to protect data in transit. Tied to a fully qualified domain name, they also provide a level of non-repudiation. SSL in its more modern incarnation, transport layer security (TLS), is a very effective layer of security.

A quick Google search for “web server certificate” or “ssl certificate” returns companies that sell basic level certificates from USD$50 (GoDaddy) to USD$700 (rest of prices in the article are in USD)  for a standard single domain and single server two year certificate. Granted, these are retail prices, but most systems engineers or security staff only deal with obtaining these certificates once every couple of years.

A better place to get competitive pricing for the major brands such as VeriSign, Thawte (part of VeriSign), GeoTrust, and RapidSSL (also part of VeriSign, see a trend here?)  is from “The SSL Store”.  This chart shows the breakdown of various vendors.

So, why do companies fork out $695 to VeriSign when they can get literally the same product for $540 from The SSL Store, or as low as $220 for a GeoTrust issued certificate?

The Past

Way back in the mid to late 90s we were provisioning e-commerce sites at a furious pace. A key for order conversion was to prevent any pop-up or alert from hitting the user’s browser. And with the concerns of credit card information, encryption alerts were B-A-D.

Back then, our browser selection was limited. Internet Explorer 4 through 6 were the major players, but there was also Netscape Navigator, Opera, and a bunch of smaller market share browsers. Each browser or operating system had a list of “trusted” certificate authorities. Browse to an HTTPS site where the certificate was signed by one of these and you were golden.

Limited Selection

Ask anyone from 1997 to 2003 where they got their certificates from and mostly likely it would be VeriSign, Network Solutions, GeoTrust, or maybe even Equifax (now part of GeoTrust). Security staff saw nothing wrong with ponying up $1,300 for a certificate per year. The CFO might take exception, but it was, and is, a cost of doing business.

Branding

VeriSign has done a fabulous job in keeping market share. The continue to compete with products, acquisitions of other Certificate Authorities (Thawte, Equifax and RapidSSL), and hammer the market with advertising. If you look at the market share statistics at Netcraft, you see that higher the trust products (low to high: domain only -> organization validated -> EV) have VeriSign leading the pack.

Another reason VeriSign has such a high market share may be due to Certificate Authority policies and reviews. The due diligence, audits, and processes to perform higher end Extended Validation reviews may require good organizational controls by the Certificate Authorities.

Does the Issuing Certificate Authority Matter?

I remember when I first found out about Thawte, the South African Certificate Authority. Certificates at 50% or less than VeriSign and easier organization validation processes. When I first proposed to replace around 30 certificates with Thawte-issued ones, the savings was around $30,000/year. There were concerns about potential browser conflicts or savvy users calling in to complain, so we did the migration slowly for the first batch of load-balanced web front-ends. In the end, there was not a single complaint or issue.

The market has normalized on certificates at varying trust levels:

With the exception of self-signed certificates, I contend it doesn’t matter if a domain or organization verified certificate comes from VeriSign, StartCom, or GoDaddy. And since Extended Validation (EV) certificates require the 20 odd Certificate Authorities to follow the same practices, there few reasons not to choose on price or convenience.

What to Look for in a Good Certificate Authority Issuer

Depending upon your needs, who you give your certificate business to depends up:

• Cost
• Locality
• Ease of Managing Certificates
• Stability
• The Extras – seals, insurance, etc.

Cost

Not necessarily the top of everyone’s list, but even Fortune 500 companies like to save costs. Look for Certificate Authorities that use resellers. Do they accept credit cards, company invoices, or other methods of payment? Are the prices competitive?

Locality

Does the Certificate Authority have a presence where you are located? If you’re in Bermuda, it’s nice to know that a major Certificate Authority, QuoVadis, is just down de road. You may find VeriSign has a great North American and European support organization, but isn’t as well versed in South America.

Ease of Management

Personally for me, besides costs, the process for validation and how easy it is to request, download and manage the [re]issuance process is key. Some of the SSL resellers have convoluted sites. Others, such as StartCom’s StartSSL, take the meaning of the word “bespoke interface” to new heights! (But their pricing model is unique and very cost effective).

Play around with various sites and talk to the staff to see just how hard is it to perform the domain or organization validation process. Some resellers have automated processes for domain-only validation while others need to make telephone calls or some other method of authentication.

Stability

How long has the Certificate Authority been in business and what is the risk the may suddenly close up shop and turn off the certificate revocation list (CRL) points. Granted the risk is limited to the duration of certificates issues by them, but having to pick a new Certificate Authority would be required.

The Extras

These are bits that to me don’t mean much of anything.  Look at these features a VeriSign Secure Site certificate gets you:

And look at company that uses them but still only uses a “blue bar” (domain validation) certificate:

Nowhere on Amazon.com’s site do they mention VeriSign. Even going into the Help section show’s limited search results:

So unless you want to put up a seal and advertise for a Certificate Authority, the only extra that may have value is the insurance–and most companies will have much better umbrella policies than the CA’s provide.

Selecting a Certificate Authority Do’s and Don’ts

Do’s

• Buy from a reseller or discount provider – They either represent top brands, or in the case of GoDaddy, simply have cheap prices. I’ve used NameCheap, RapidSSL (via reseller), Enom, and GoDaddy.
• Take advantage of multi-year deals and discounts for certificates – Some providers will give certificates for free if you host a domain with them.
• Take advantage of wildcard and subject alternate name (SAN) certificates – If you are protecting more than a couple domains, a wildcard certificate can be very cost effective.  The same holds true for SAN certificates. Beware the costs as you add additional servers or domain names.
• Export and backup the certificate – Make sure the private key and certificate and exported and stored somewhere safe. Some Certificate Authorities can reissue a certificate, why pay for something that should be good system practice (backup).

Don’ts:

• Buy directly from a major brand – I wonder how many people actually do buy directly from VeriSign instead of a reseller.
• Break the usage agreement – If the agreement says you pay for each physical or virtual server the certificate is used on, then pay the provider or look to one that allows multi-server use.
• Base selection just on price – Certain usage patterns may place convenience or the locality of a Certificate Authority over price.

Conclusion

Hopefully this article has presented some information to help people select an appropriate Certificate Authority and save some money. In looking back upon the hundreds of certificates I’ve purchased personally and for clients, the prices continue to drive down towards zero. What cost $1,300 in 1997 now costs $9 to $11.

And as prices drop on domain and organization certificates, the browser and Certificate Authorities continue to develop “new-and-improved” products at higher prices.  What do the Certificate Authorities have in store for us once the price of an EV certificates have fallen?

Using a Startcom [...]]]> For a very low cost, it’s easy to use StartSSL (Startcom) certificates on the Citrix NetScaler product line. This is includes the free NetScaler VPX Express edition. A lot of problems I see with others configuring the NetScaler is related to either self-signed certificates or the use of intermediate (e.g., chained) certificates.

Using a Startcom certificate allows for a trusted CA (no certificate errors) and the NetScaler makes it easy to configure intermediate certificates. We’ll go through the entire process of creating a certificate usable on the NetScaler. The process is also the same for any chained certificate.

The Objective

We want to secure a connection to virtual server on the NetScaler using SSL for a low cost (free for a 30 day certificate or USD$50 for a two-year certificate). Specifically:

• Low-cost certificate (or certificates)
• Valid for all major browsers or servers that will connect to the NetScaler
• Imported and bound to a NetScaler Access Gateway Virtual Server

The Environment

NetScaler VPX Express with the following configuration:

• Version 9.2 (9.1 or previous versions should work, maybe with changes to the GUI)
• NetScaler IP (NIP) and Mapped IP (MIP) already configured
• Commands via GUI
• Usable IP address for a virtual server (to test)
• Administrative access (nsroot) to the NetScaler

Other required items:

• A valid public domain (required for Startcom certificate issuance)
• Workstation or server with OpenSSL tools loaded
• Startcom account (class 1 or class 2, meaning you have a client certificate)

Create the Certificate

Prior to any NetScaler configurations, we’ll first create the certificate and prep the files for the NetScaler. This include the private key, signing request, then downloading the certificate and the certificate chain (intermediate and root certificates). You can do these same steps from the NetScaler GUI, but I’ve always found having the OpenSSL toolkit around to be consistent across platforms and useful for troubleshooting problems.

Private Key and Certificate Signing Request (CSR)

First create a private key of suitable size (I’m using an URL from my domain as an example):

D:\Temp>openssl genrsa -out test.gavinadams.org.key 2048
Generating RSA private key, 2048 bit long modulus
.........................................................+++
.................+++
e is 65537 (0x10001)

Then create the certificate signing request (CSR):

D:\Temp>openssl req -new -key test.gavinadams.org.key -out test.gavinadams.org.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:GA
Locality Name (eg, city) []:Cumming
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Not used by Startcom
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:test.gavinadams.org
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

D:\Temp>ls test*
test.gavinadams.org.csr  test.gavinadams.org.key

A couple things to note:

• Organizational name is not used. Common name is not used. Actually, everything but the private key signing portion is thrown out when submitting the request to StartCom. I enter them for consistency though.
• There is no password on the private key or CSR, so be careful and protect that key!

Create the Certificate

Login into the control panel at StartSSL and then go to the StartSSL PKI page. Use the Certificates Wizard to start the process. At different points you will need to copy and paste the contents of the local .csr file and enter the URL for the common name field.

To keep this short I’ll skip all the steps on the StartCom website and jump the end steps (email me if you’d like a tutorial on managing StartSSL certificates):

Select all and copy the contents to a local text editor and save with the .key file (test.gavinadams.org.crt in this example). You can delete the CSR file at this point.

Download Startcom CA Certificates

Now download the root and appropriate intermediate certificate. The root is the same for all certificates, but the intermediate will depend upon your class. In this example, it is a class 2 certificate, so I download the Class 2 Intermediate Server CA file.

Save the StartCom Root CA  file as startcom-ca.pem

Save the intermediate file as startcom-sub.class2.server.server.ca.pem

Install Certificates into the NetScaler

At this point we have the following files in a temporary directory (the .csr file is not needed but I normally keep them around until I complete housecleaning):

From the NetScaler configuration page, select SSL->Certificates, then Add… from the bottom. Use the GUI to upload the certificate and key along with the root and intermediate CA.

Enabling the notification period is optional. I rely upon my network monitoring to provide notice when a certificate is getting close to expiration.

For this and and the intermediate certificates there is no corresponding private key, so only populate the Certificate File Name field.

Finally, on the NetScaler GUI the SSL window should show the three certificates loaded, along with the default self-signed certificates of the NetScaler:

My CA names are different as this is on a box where they are already loaded, so note the names in the first column when we link the certificate together. Note the expiry date on the intermediate certificate. The intermediate certificates expire much sooner than the root CA. This is why I download the complete chain from StartCom each time I issue a new certificate. Any new intermediate certificates would need to be uploaded.

Link the Certificates

Probably the easiest part of the process. I reckon the linking process is simply combining the PEM formatted certificates into a single file. But the GUI makes it easy. First link the certificate we created to the intermediate by right-clicking on the certificate and selecting Link…

then select the intermediate certificate and press OK:

From the certificate window, select the intermediate certificate, right-click, and link to the Root CA:

Housekeeping

At this point we have the certificates and private key loaded in the NetScaler. Back everything up at this point! Before I got into the habit of creating a passphrase protected PKCS12 file, I may have misplaced the certificate, or exposed the unprotected key file. I now create a p12/pfx file with the certificate and key in it. Then it gets backup up to a protected site (Keepass or something similar). finally, the Keepass file gets uploaded to Dropbox and synced across my multiple workstations.

D:\Temp>openssl pkcs12 -export -in test.gavinadams.org.crt -inkey test.gavinadams.org.key -out test.gavinadams.org.p12
Enter Export Password:
Verifying - Enter Export Password:

D:\Temp>ls *p12
test.gavinadams.org.p12

This is important for Startcom issued certificates. I love the price for issuing certs: all you can eat for two years for USD$50 (class 2 validation), but if you lose the certificate, it’s a USD$25 charge to have it added to the CRL.

Access Gateway Test

Okay, the certificate has been created, all portions uploaded, and backed up for safe keeping. Now go to Access Gateway->Virtual Servers and select Add… from the bottom of the display:

Important parts are the Name, IP address, and certificate selected. If testing, choose an unused IP address and ensure a DNS or hosts file entry exists, then use a browser to hit the site (Firefox 3.6 used here):

You should get a validSSL lock from the log in page. This validates the NetScaler and the certificate is working fine. At this point you can remove the Access Gateway Virtual Server. The certificates are still on the NetScaler and can be bound to other items where SSL is used.

Summary

Hopefully not too long of a post. Briefly:

1. Create a Startcom web server certificate
2. Upload the certificate, private key and Startcom CA certs (root and intermediate) to the NetScaler
3. Link the certificates on the NetScaler and bind the web server certificate to a Access Gateway Virtual Server
4. Use a web browser to verify the SSL connection

By default, all the tutorials for installing XenDesktop use the defaults. This means that [...]]]> XenDesktop 4 has raised the bar for virtual desktop (VDI) solutions. It’s now easier to provide a virtual desktop to users on differing operation systems and platforms. And having Citrix on the iPhone / iPad is just amazing eye candy too.

By default, all the tutorials for installing XenDesktop use the defaults. This means that under Windows, using a browser to connect and launch a session from web interface uses the online plug-in module. It works, provides multi-monitor capability, but has display artifacts and no nifty bar to manage USB connection and such. Besides this client, the Desktop Viewer can also be used as the default (if installed).

With the 11.x and 12.0 clients it’s easy to change. First install the Citrix Online plug-in (not the Citrix Online plugin – web which is smaller and doesn’t include the Desktop client) from here. You’ll have to navigate to the OS X client, Citrix seems to change the URL for the downloads.

From the web interface server that services XenDesktop, browse to the conf directory and edit webinterface.conf. For example, /Citrix/WebDesktop2 is located here:

Edit the file and search for ShowDesktopViewer and change the line from:

# ShowDesktopViewer=Off

to the following:

ShowDesktopViewer=On

Next time a session is launched, the Desktop Viewer will be used instead of the online plugin. This doesn’t work under OS X as there really isn’t a better client than Desktop Viewer yet. Thanks to Richard Parmiter for documenting this!

Hint: To get mult-monitor under Desktop Viewer, re-size to something less than full screen, move the window over the two monitors and re-size to full screen. This setting will persist across sessions.

Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears do the vSphere (ESX/ESXi [...]]]> This is an update post to reflect the differences in vCenter 4.1 vs the older vCenter 25 install. The older post can be found here.

Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears do the vSphere (ESX/ESXi — err vSphere Hypervisor) hosts, but when your VDIs suddenly can’t be reached, it’s a bad thing. I’m sure other products may have the same issue.

By default, vCenter will create a self-signed certificate issued to “VMware default certificate“. Unlike previous vCenter installs, the certificate is valid for 10 years, but still can cause problems for third parties that want to see the proper common name (e.g., FQDN of the vCenter server).

In our case, since we’re not publishing any SSL services to the public and already have a Microsoft Certificate Authority, we can create and sign our own vCenter certificate. And just like the newer version of vCenter, we’ll set it up for 10 years too.

This can be completed in just under 15 minutes if all the prerequisites are in place. Took me an hour (including this documentation).

Environment Summary

For this process to work, the following assumptions are made:

• Active Directory installed and Certificate Authority installed (in my case, it’s on a Windows 2008 Domain Controller with Certificate Authority and Certificate Authority Web Enrollment )
• DNS used for vCenter and internal FQDN name
• vCenter server part of the domain, Domain Admin access to it
• vCenter installed with local database (SQL Server 2005 Express) and using SYSTEM account – People commented on my previous related post about other steps required for database connectivity
• Using the included web services that comes with vCenter (IIS users on your own for this one)

To test, we’ll use a browser from a workstation and the XenDesktop DDC to validate connection (make sure the root CA certificate is added to the Trusted Roots for the Computer Account on each test and production server)

Prep vCenter

Since vCenter 4.1 now requires a 64-Bit Operating System (Server 2008 R2 Standard in my case), we’ll download the OpenSSL for Windows 64-Bit version.

Download OpenSSL for Windows (binary for the 64-bit version  v1.0.0a is here) You may have to install the Visual C++ 2008 redistributable package first.

Verify the private key exists in: C:\Users\All Users\VMware\VMware VirtualCenter\SSL\rui.key (you will need to change permissions to allow your user account to access this directory and files)

Copy all the files in C:\Users\All Users\VMware\VMware VirtualCenter\SSL to a temporary location such as c:\temp\vcenter\oldssl (create if needed)

Open a command shell and go to c:\temp\vcenter\newssl (create if needed)

Generate the new RSA private key (2048 bit) and the certificate request (most important is that the common name must be the FQDN of the server). For the CSR, I normally use the common name value.csr, but since we’re working with rui.*, we’ll use that here too:

C:\temp\vcenter\newssl>c:\OpenSSL-Win64\bin\openssl.exe req -newkey rsa:2048 -keyout rui.key -nodes -days 3650 -out rui.csr
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
.............................+++
......................................+++
writing new private key to 'rui.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Georgia
Locality Name (eg, city) []:Cumming
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gavin Adams
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:vcenter.peanuts.local
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

C:\temp\vcenter\newssl>dir
Volume in drive C has no label.
Volume Serial Number is 204A-99B1
Directory of C:\temp\vcenter\newssl
04/16/2010  03:50 PM    <DIR>          .
04/16/2010  03:50 PM    <DIR>          ..
04/16/2010  03:50 PM             1,024 .rnd
04/16/2010  03:49 PM             1,675 privkey.pem
04/16/2010  03:50 PM             1,679 rui.key
04/16/2010  03:50 PM             1,005 rui.csr

From the vCenter system, browse to the certsrv URL for your Active Directory Certificate Authority (normally https://dcname/certsrv and probably will require a valid Active Directory user):

Select Request a certificate, advanced certificate request, and then Submit a certificate using base-64…. Past the entire contents of the rui.csr (open in Notepad, select all — it will be all on one line, but a CTRL-A CTRL-C will do fine) in the Saved Request box, select Web Server for Certificate template:

At this point the certificate will be signed. On the next page select Base 64 encoded then Download certificate and save as rui.crt in c:\temp\vcenter\newssl

From the private key and certificate, create the PFX fie:

C:\temp\vcenter\newssl>c:\OpenSSL-Win64\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Stop the following services:

VMware VirtualCenter Management Webservices
VMware VirtualCenter Server

Copy all the files in the newssl directory to : C:\Users\All Users\VMware\VMware VirtualCenter\SSL\ replacing the existing ones. Don’t worry, we backed these up.

Now restart the services in this order (unsure if it matters):

VMware VirtualCenter Server
VMware VirtualCenter Management Webservices

Use browser and navigate to the URL of the vCenter (e.g., https://vcenter.peanuts.local) and verify the certificate is valid. Open the vSphere client and verify all looks okay. After restarting the services, you will need to reconnect to the ESX / ESXi hosts and re-authenticate with root credentials on each server. This is because the SSL trust between the two has changed and a new trust relationship needs to be established. Another reason for a longer term certificate!

Problems and Resolution

I’ll update the post with corrections, but with different configurations, we may run into different issues.

By default, vCenter will create a self-signed certificate with just the host name. [...]]]> Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears does the ESX hosts, but when your VDIs suddenly can’t be reached, it’s a bad thing.

By default, vCenter will create a self-signed certificate with just the host name. In our case, since we’re not publishing any SSL services to the public and already have a Microsoft Certificate Authority, we can create and sign our own vCenter certificate. And just like the newer version of vCenter, we’ll set it up for 10 years too.

This can be completed in just under 15 minutes if all the prerequisites are in place. Took me an hour (including this documentation).

Environment Summary

For this process to work, the following assumptions are made:

• Active Directory installed and Certificate Authority installed (in my case, it’s on a Windows 2008 Domain Controller with Certificate Authority and Certificate Authority Web Enrollment )
• DNS used for vCenter and internal FQDN name
• vCenter server part of the domain, Domain Admin access to it
• Using the included web services that comes with vCenter (IIS users on your own for this one)

To test, we’ll use a browser from a workstation and the XenDesktop DDC to validate connection (make sure the root CA certificate is added to the Trusted Roots for the Computer Account on each test and production server)

Prep vCenter

Download OpenSSL for Windows (binaries can be found at: http://www.slproweb.com/products/Win32OpenSSL.html) . You may have to install the 2008 redistributable package first.

Open a command shell and go to c:\temp\vcenter\newssl (create if needed)

Verify the private key exists in: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key

Copy all the files in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL to a temporary location such as c:\temp\vcenter\oldssl (create if needed)

Generate the new RSA private key (2048 bit) and the certificate request (most important is that the common name must be the FQDN of the server). For the CSR, I normally use the common name value.csr, but since we’re working with rui.*, we’ll use that here too:

C:\temp\vcenter\newssl>c:\OpenSSL\bin\openssl.exe req -newkey rsa:2048 -keyout rui.key -nodes -days 3650 -out rui.csr
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
.............................+++
......................................+++
writing new private key to 'rui.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Georgia
Locality Name (eg, city) []:Cumming
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gavin Adams
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:vcenter.peanuts.local
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

C:\temp\vcenter\newssl>dir
Volume in drive C has no label.
Volume Serial Number is 204A-99B1
Directory of C:\temp\vcenter\newssl
04/16/2010  03:50 PM    <DIR>          .
04/16/2010  03:50 PM    <DIR>          ..
04/16/2010  03:50 PM             1,024 .rnd
04/16/2010  03:49 PM             1,675 privkey.pem
04/16/2010  03:50 PM             1,679 rui.key
04/16/2010  03:50 PM             1,005 rui.csr

From the vCenter system, browse to the certsrv URL for your Active Directory Certificate Authority:

Select Request a certificate, advanced certificate request, and then Submit a certificate using base-64…. Past the entire contents of the CSR (open in Notepad) in the Saved Request box, select Web Server for Certificate template:

At this point the certificate will be signed. On the next page select Base 64 encoded then  Download certificate and save as rui.crt in c:\temp\vcenter\newssl

From the private key and certificate, create the PFX fie:

C:\temp\vcenter\newssl>c:\openssl\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Stop the following services:

VMware VirtualCenter Management Webservices
VMware VirtualCenter Server

Copy  all the files in the newssl directory to : C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ replacing the existing ones. Don’t worry, we backed these up.

Now restart the services in this order (unsure if it matters):

VMware VirtualCenter Server
VMware VirtualCenter Management Webservices

Use browser and navigate to the URL of the vCenter (e.g.,  https://vcenter.peanuts.local) and verify the certificate is valid. Open the vSphere client and verify all looks okay. After restarting the services, you will need  to reconnect to the ESX / ESXi hosts and re-authenticate with root credentials on each server. This is because the SSL trust between the two has changed and a new trust relationship needs to be established. Another reason for a longer term certificate!

So, after downloading the ISO image (at least the DVD can be [...]]]> VMware’s Update Manager has always been too complex and cumbersome for small installations. However, back in the EX 3.5 days, it at least worked. Late last year when vSphere 4 Update 1 came out, I once again tried using good ol’ Update Manager.

So, after downloading the ISO image (at least the DVD can be used to build new hosts) I went through the process of baseline creation, compliance, added the host, and viola, Upgrade is not supported from host version 4.0.0 to blah blah blah.

Luckily, esxupdate to the rescue. I uploaded the .zip file bundle (not the ISO image, so another 900MiB download) to VMFS storage and ran the update script from the location of the .zip file after putting the host into maintenance mode:

# esxupdate --bundle=ESX-4.0.0-update01a.zip update

Performed a reboot, and the host is now running at ESX 4.0.0 build 208167. Caveats:

• Make sure 3rd party monitoring and management packages are uninstalled first (e.g., HP or Dell)
• Maintenance mode (natch)

VMware’s market lead is based on large scale management and features you cannot find (yet) in Xen or Hyper-V. I love most features and the UI of vCenter, but the add-ons really need to be better managed.

In the past, simply double-clicking on the .p12 file would prompt for the passphrase and import it into the [...]]]> I love OS X and every iteration has gotten better and better. But every once in a while tasks that should be simple–aren’t. Take the case of trying to add a S/MIME certificate to the Keychain.

In the past, simply double-clicking on the .p12 file would prompt for the passphrase and import it into the login chain. After getting my certificate issued by StartSSL and stored in Firefox, I exported the certificate and private key, set a passphrase, double-clicked, and….

An error has occurred. Unable to import an item. The contents of this item cannot be retrieved. You failed to provide the necessary administrator authorization. (Added so the search engines will pick this up)

And so the battle commenced. There really isn’t a lot out there discussing when Keychain Access fails. The closest similar discussion was by Midori Green (email thread here). The error was different, but it was the same attempt to import a PKCS12 file.

I tried using openssl to rearrange the certificates in the file (after exporting into PEM format), tried adding/removing/changing the private key passphrase, import/export from a Windows machine in .PFX format, and even trying to recreate the PKCS12 file from its’ constituent parts.

Luckily, I ran across this post on krypted.com that mentioned the CLI command security. After placing the exported .p12 file (from Firefox) in a directory and launching terminal, I was able to use the command:

linus:gadams$ security import startssl-smime-cert.p12 -f pkcs12 ~/Library/Keychains/login.keychain
1 identity imported.
2 certificates imported.

And bam!, the certificate loaded. Composing a new message in Mail.app showed the signing and encryption boxes. Although I still get invalid signatures when sending rich text format messages, plain text are properly getting signed.

I am curious exactly what command is executed when you double-click on a certificate file. I assume the Keychain access application makes underly calls to security, but I’d like to be able to trace the steps it takes.

Side note, I’m going to do an opinion piece of certificate authorities in general and digital certificates, SSL, S/MIME, and all that rot. There are some great options for small companies and individuals to get certificates at a cheap or free price. No Verisign or GTE Cybertrust (err Verizon Business) $$$$$ prices need apply!