Enabling HTTP Strict Transport Security (HSTS) For WordPress

If you are a WordPress site administrator, one of the things you can do to improve SEO results and security is secure your site with SSL. Yes, even if you aren’t doing transactions like ecommerce, paypal, etc. using SSL is still recommended. Depending on your WordPress hosting company, they may even have free SSL certificates for you to use. But there are different flavors and configurations of SSL that can improve or detract from your security posture. One feature that was recently brought to my  attention is HTTP strict transport security, or HSTS.

HSTS, in short, tells your browser that you only want it to use (and enforce) SSL connections. Attempts to downgrade to non-encrypted communications are prohibited. HSTS is a flag that you configure on your WordPress site, and is not enabled by default (that I’m aware of). Since SSL configuration can be tricky, and you can end up with mixed mode content, I recommend a WordPress plug-in called Really Simple SSL.

As the plugin name implies, this makes configuring SSL (with HSTS) super easy and all from the GUI. It also scans your WordPress site for potential mixed content issues and brings them to your attention. My site had a couple of flagged issues that I fixed. The free version of the plug-in doesn’t configure/test HSTS for you, but their premium version does (and makes it 1-click easy).

However, it may still take a bit of configuration tweaking to fully enable HSTS. First, after you enable HSTS in the plugin, go to hstspreload.org and check your results. In my case, I had two errors. My site is currently error free, so I’m using aol.com as an example for what you may see.

First, ignore the no HSTS header error. That is likely caused by the second error and does not mean Really Simple SSL didn’t do its HSTS configuration. I use WP Engine as my provider, so I contacted their help desk and gave them a copy of the error. They did some back-end redirection magic and fixed up the redirection issue in about 15 minutes. My redirection issue was slightly different from AOL’s problem, but caused the same red failure message. After your redirection issue is fixed, re-try the scan. In my case, it came back with a green screen showing everything is good. Next, you can submit your site to be included on the global HSTS list, which I also did. Many browsers like Chrome and Firefox use the HSTS list for additional security measures.

And just to make sure my SSL is in top notch, I went over to SSL Labs and ran a test. And yes, my site is now rated A+, which is exceptionally good. It even catches the fact I’m successfully using HSTS.

And there you go! A simple, but not totally free, way to deploy and check HSTS on your WordPress site. Given the plug-in is just a few dollars, and helps fix up a variety of SSL issues besides HSTS, I think it’s money well spent.

vSphere 5.5 Toolkit Updated

This weekend I did a minor update to my VMware vSphere 5.5 SSL Toolkit script. It’s now at v1.59. I updated the OpenSSL download to use 0.9.8.zb, and also added a primitive PowerShell 3.0 check. PowerShell 3.0 and higher has always been required, but now I try and check for it. If you are running PS 3.0 and still get an error, then please leave a comment in this post. The logic isn’t all that intelligent, so may need tweaking.

If you aren’t familiar with my vSphere 5.5 toolkit script, then you can check out Part 8 of my 19 part vSphere 5.5 installation series. As always, you can download the latest version from vExpert.me/toolkit55.

Join the over 10,000 downloads of my Toolkit script and make your SSL life a lot easier.

VSS Labs vCert Manager Part 2

This is part 2 of the VSS Labs vCert Manager installation and configuration series. In Part 1 we got vCert Manager installed, and secured with a trusted SSL certificate. In this section we will get into the nuts and bolts configuration and start replacing certificates.

vCert Manager Configuration

1. First we will setup a SMTP server, which is used to send email notifications of various events such as expiring certificates. Login to vCert Manager and from the main menu select Settings. The in the left under Company Settings select Portal Settings.

2. Enter the SMTP server details for your organization. Notice that the tool supports SSL encrypted SMTP, and SMTP authentication. You can even test out the SMTP authentication from right within the tool. Here you can also setup different notification settings. I’ll just leave the defaults here.


3. You can also configure SYSLOG settings. You can easily change the port number, and protocol (TCP/UDP). This is great for services such as Splunk, where you can customize different SYSLOG listeners on different ports. Click the Save icon on the left to save all of your settings.


4. In the left pane click on Company Profile and fill out the details. These will be used for certificate generation.


5. In the left pane click on My Account. Here you can change the password for the default ‘admin’ account. Change it to a nice complex password.


6. In the left pane click on Sites change the site name to something relevant to you. This should reflect where the vCenter components reside. Mine are in San Diego.


7. The tool also supports role based access controls (RBAC), and you can add additional accounts that have different levels of permissions. Roles include Home, Cert Manager, Administration, Settings, Reports, Logs, About.

8. Now we need to establish a connection to our Microsoft CA. On the main page click on Administration in the top banner. In the left pane click on Certificate Authorities. Click on the green Add button. Fill in the details as needed. I would suggest setting up a service account that has proper permissions in your CA, vice your normal admin account like I show below. Better security, and better traceability. Shame on me. Click on Get Templates and select your VMware SSL template that you’ve already created.


After you add the CA, it will now be shown in the middle status pane.


9. In the left pane click on Infrastructures. Click on the green Add button. Enter your vCenter details, and service account information. Again, use a service account here and not your administrator account like I did. Test the connection to validate the information.


10. Now you will probably get a large certificate warning screen, since your vCenter certificate is probably not trusted at this point. Click on the I trust this certificate button.
















11. Next up is a credentials page where you need to enter passwords several times for the various components that it detects. After all of the passwords are entered, click on the Trust buttons for SSO and Inventory service. Note, that if you are using Windows authentication or SQL express for vCenter, just enter a dummy password in the DB Password field.



12. On the main menu bar click Cert Manager. You should now get a nice little graphic with the quantity of discovered components.


13. Click on the vCenter FQDN and you will see a table format of the same information. Click on the graphic to enlarge it.


We are now ready to actually replace the certificates. That will be coming up in Part 3. Stay tuned!


VSS Labs vCert Manager Part 1

Last August I wrote a blog post about this great new VMware SSL tool by VSS Labs called vCert Manager, which replaces many of your VMware SSL certificates all from the comfort of a nice GUI. It’s a full certificate lifecycle management tool for VMware vSphere and related components. For the full feature list and comparison with the free VMware tools, check out my post here. I’ll wait for as you read through that long article.

Ok with that out of the way, this time up I’ll actually walk you through the installation process, and see how easy it is to replace your vCenter 5.5 and ESXi host SSL certificates, all from a nice GUI. vCert manager is a licensed tool, but as you will see, has a lot of great features that no other tool that I’m aware of has.

If you are cash strapped and can only afford a free tool, then please remember my vSphere Toolkit script + the VMware certificate replacement tool combination. While the combination is less painful than the manual procedures, they fall very much short of the vCert Manager tool in terms of both functionality and ease of use.

VSS Labs has a special vExpert program, where you can get a NFR license that supports two vCenter servers and up to 10 ESXi hosts, for non-production usage. Their standard eval license supports 1 vCenter and 5 ESXi hosts.

What does it Update?

The list below is all of the VMware components that vCert Manager v1.2 can update:

  • vCenter 5.0: vCenter, Update Manager, Inventory Service, web client
  • vCenter 5.1: SSO, Inventory Service, vCenter, Web Client, Update Manager, Orchestrator
  • vCenter 5.5 (single location): SSO, Inventory Service, vCenter, Web Client, Update Manager, orchestrator
  • ESX/ESXi: 4.0 through 5.5

My Environment

In my environment I have Microsoft vCenter 5.5 server, and three ESXi 5.5 hosts. All of the vCenter components are installed on one server. I also have a two tiered Microsoft CA hierarchy. The root is offline, and I have an online issuing CA. Both are Windows Server 2012 R2. I have also setup a certificate template for VMware products, which you can read about here. You must have a certificate template, so if you don’t, go configure one following my guide.


1. I provisioned a Windows Server 2012 R2 VM from my standard template, which has no additional roles or features beyond .NET Framework 3.5 and .NET Framework 4.5. The tool is IIS and ASP.NET based, so we need to install IIS and ASP.NET to get started. Launch Server Manager and select the Web Server (IIS) role.


2. On the Features page expand .NET Framework 4.5 and select ASP.NET 4.5. Click through the rest of the wizard and wait for the components to install.


3. Go back to server manager and under Web Server enable ASP.NET 4.5, ISAPI Extensions and ISAPI Filters. Wait for the installation to complete.



4. Download the VSS Labs vCert Manager binary and start the installer. Click through the wizard until you get to the following screen. I chose the defaults, which are shown below. If you wanted, you could create a custom service account which the application pool would run under.

VSS Labs

5. Next up you can specify an account which the service uses to logon. Again, I left the default here. By using this default the computer machine account will need SQL database permissions, which I cover later.


6. Now we need to specify the SQL database connectivity, so that it can create and use a SQL database. I simply entered the database server, database name, and port. A great feature is supporting SQL encryption. According to the install guide a future version will support a system ODBC connection. The account I was logged in as has SQL sysadmin rights, so the Test Connection passed.


7. Finally you can change the installation directory. I choose the default here. The installation took less than a minute after I completed the wizard.


SQL Permissions

1. Go to your SQL server and add a new security login. Use the computer name (followed by a $) that vCert manager is installed on and change the database to the vCert manager database that was created during the installation process.






The installer will create a non-trusted SSL certificate, which I recommend we replace with one from your trusted CA. In my case I have an autoenrollment policy so that my computer already has a machine certificate that I can bind with in IIS. If your machine does not already have a machine certificate, then issue one and install it in the machine’s certificate store.

1. Open IIS and navigate to the vCert Manager site in the left pane. In the right pane click on Bindings then modify the bindings for the 8056 port entry. Select the thumbprint for your trusted machine certificate.



2. Open a web browser and navigate to https://FQDN:8056 and you should get a nice looking login page. They suggest using Chrome v26, Firefox 20 or IE 10. I used IE 11 and didn’t notice any issues. Verify there are no SSL warnings.

vCert Manager

And there you go..vCert manager is now fully installed and secured via a trusted SSL certificate. In the next installment we will dive into the management interface and start replacing certificates.

vCenter 5.5 Update 1b Now Out

2014-06-13_8-54-42Earlier this year the Heartbleed OpenSSL vulnerability came to light, and many products from many different vendors were affected. Heartbleed is a very serious vulnerability, and you should conduct a thorough audit to validate all of your software and hardware components are not affected. My bet is that many of your product are affected, and VMware was far from alone in having to issue software updates. Fresh off the presses is vCenter 5.5 Update 1b, which addresses CVE-2014-0224, Heartbleed. They have updated their OpenSSL libraries to 0.9.8za, 1.0.0m and 1.0.1h. I find it interesting that all three versions are used within the product.

As usual, this minor update includes some other bug fixes a well and not major new features. Other resolved issues include:

Host profile answer file might not be applied when you reboot the ESXi host
After you restart the vCenter services, if you use Auto Deploy to reboot a stateless ESXi host, the host profile answer file might not be applied to the ESXi host and the host configuration might fail. This issue occurs if the reference host is not available.

Under certain conditions, Virtual SAN storage providers might not be created automatically after you enable Virtual SAN on a cluster
When you enable Virtual SAN on a cluster, Virtual SAN might fail to automatically configure and register storage providers for the hosts in the cluster, even after you perform a resynchronization operation.

As is typical with VMware release notes there is a handy dandy list of known issues, which you should thoroughly read through before deploying this update. A few known issues that jumped out at me include:

  • Upgrade from vCenter Single Sign-On 5.1 Update x to 5.5 Update 1a fails if the password set for administrator@vsphere.local contains double quotation mark (“)
  • After you upgrade vCenter Server 4.x to 5.5 Update 1a, vCenter Server is inaccessible through vSphere Web Client (Due to SSL issues)
  • Attempts to upgrade from earlier versions of vCenter Single Sign-On 5.5 to 5.5 Update 1a might fail if the Windows Error Reporting Service is disabled
  • Installation using Simple Install fails on Windows Server 2008 R2 and Windows 2012 hosts


Given the extreme severity of the Heartbleed issue, this is one security update that I recommend you immediately start testing in your lab environment and roll out into product once you are satisfied that it hasn’t broken anything in your environment. You can find the full release notes here. You can download the updated ISO here.

vSphere 5.5 Toolkit v1.57 Released

Now that vSphere 5.5 has been out for a few months, if you haven’t already started working with it in your test environment, you should! A lot of great new features, and major improvements to the SSO experience. However, you still may find it a bit challenging to secure vCenter and ESXi hosts with trusted SSL certificates. So hot off the press is a minor bug fix version of my vSphere 5.5 Toolkit script. You can download the new version here. In case you aren’t familiar with it, here are some of the features:

  • Downloads and installs the proper version of OpenSSL (0.9.8.Y) if it’s not already installed
  • Creates 2048 bit RSA private keys in the proper format
  • Creates a directory for each service bundle of SSL certificates
  • Generates seven OpenSSL configuration files, one for each certificate, in the appropriate directory
  • Downloads both root and subordinate root public certificates
  • Submits the CSRs to the online CA and downloads the certificates
  • Creates the needed service PEM files for the vCenter certificate automation tool
  • Creates the required root/subordinate PEM files
  • Handles the special SSO 5.5 certificate requirements
  • Automatically uses the hostname of the server you run the script on for all certificates
  • Creates a pre-filled vCenter Certificate Automation environment script – Just run!
  • Works with offline CAs
  • Creates SSO 5.5 certificate replacement files – Only used if manual replacing certs
  • Creates customized SQL vCenter and VUM database creation script
  • Creates SQL ODBC DSNs for vCenter and VUM
  • Automatically downloads and installs SQL 2008 R2 or SQL 2012 client package
  • Linux vCenter Server Appliance support for online minting and offline CSR creation
  • Creates certificates for Auto Deploy, Dump Collector, Syslog collector, Authentication Proxy
  • Support Microsoft CAs that require manual certificate approval

Version 1.57, which you can download here, has a couple of minor fixes:

  • More robust handling of non-internet connected servers
  • Removed line continuation characters that caused issues for some people
  • Fixed bug when no subordinate CA was present (v1.56)
  • Changed Microsoft “renewal” default to 0 for root/subordinate (v1.56)

Although the script was developed for all-in-one vCenter servers, it will work for instances where services are distributed across several servers. You will just have to be intelligent about using the correct hostnames and merging together directories with the proper certificates. Not rocket science, but does take a little manual work.

In case you missed it, I also have a 19 part vCenter 5.5 installation and configuration series that covers how to use the Toolkit script in gory detail. You can check out that series here. The ESXi SSL portion of the tool also works with vSphere 5.0 and 5.1, so you aren’t just limited to 5.5 hosts.

1-11-2014 2-27-28 PM

Windows Server 2012 R2 Two-Tier PKI CA Pt. 2

1-5-2014 2-43-05 PMNow that our root Windows Server 2012 R2 certificate authority is installed and published to Active Directory from Part 1, it is time to bring online our subordinate CA. The subordinate CA will be our online issuing CA, since it will be the CA which issues all certificates, be they for users, computers, ESXi hosts, etc. The VM will be joined to the domain, and be online 100% of the time.

As with the offline root, you should perform hardening of this VM as well. Enabling the Windows firewall (or a third party one), anti-virus software, Microsoft EMET, and following Microsoft security baseline settings are all strongly recommended. If you have security software that can monitor file changes or system integrity, that too would be a great idea. Auditing tools such as Splunk, for real time alerting, would be ideal for defense in depth.

Install Windows Server 2012 R2 Subordinate CA

1. Use Notepad and create a file called CAPolicy.inf in C:\Windows on your subordinate VM. Use the code snippet below, but change the URL to match that previously used in configuring your offline root.

Signature="$Windows NT$"
Notice="Legal Policy Statement"

4. Run the following PowerShell command. Change the CACommonName as needed. The command will completely instantly.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Add-WindowsFeature Adcs-web-enrollment
Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CACommonName "IssuingCA-D002MISC01" -KeyLength 2048 -HashAlgorithm SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

5. Copy the resulting request (see the yellow information text from the last command for the path and file name) to the offline CA.

6. On the offline CA type the following command, using your filename:

certreq -submit D002MISC01.contoso.local_IssuingCA-D002MISC01.req

7. You will now see that the request is pending. Take note of the RequestId, as it will be unique to you.

1-4-2014 7-47-29 PM

8. Open the CA Manager snap-in on your offline root and issue the pending certificate.

1-4-2014 7-48-25 PM9. While still on the offline CA, enter the following command to download the new certificate. Replace “2” with your request ID, and change the filename as you see fit.

certreq -retrieve 2 c:\D002MISC01.contoso.local_IssuingCA-D002MISC01.crt

10. Copy the certificate file to the online subordinate CA. Note: Do NOT place it in the pki directory. Run the commands below to install the new certificate. Once the certificate is installed, delete the file and empty the trashcan.

Certutil –installcert a:\ D002MISC01.contoso.local_IssuingCA-D002MISC01.crt
start-service certsvc
copy c:\Windows\system32\certsrv\certenroll\*.cr* d:\pki\

Configure Subordinate CDPs

1. Next up we need to configure the proper CRLs for our subordinate CA. Enter the following commands in an elevated Powershell on your subordinate CA.

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
Add-CACRLDistributionPoint -Uri http://www.contoso.local/pki/%3%8%9.crl">http://www.contoso.local/pki/%3%8%9.crl -AddToCertificateCDP -Force
Add-CACRLDistributionPoint -Uri file://\\D002Misc01.contoso.local\pki\%3%8%9.crl" file://\\D002Misc01.contoso.local\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia http://www.contoso.local/pki/%1_%3%4.crt" http://www.contoso.local/pki/%1_%3%4.crt -Force
Certutil -setreg CA\CRLPeriodUnits 2
Certutil -setreg CA\CRLPeriod "Weeks"
Certutil -setreg CA\CRLDeltaPeriodUnits 1
Certutil -setreg CA\CRLDeltaPeriod "Days"
Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"
Certutil -setreg CA\ValidityPeriodUnits 5
Certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\AuditFilter 127
restart-service certsvc
certutil -crl

CA Delegation

1. Now that our online subordinate CA is up and running, for the most part, it is a good idea to delegate who has rights to manage the CA and issue certificates. I’m going to create two roles: One that can manage all aspects of the CA, and another that can just mint specific certificates. In AD create two groups: Role_CA Manager and Role_Issue Certificates. Or use whatever names you like.

2. On your subordinate CA, launch the CA MMC Snap-in. Right click on the CA name, open the properties, and select the Security tab, and add the Role_CA Manager group. Give it Manage CA permissions. If you want, you can remove rights from Domain Admins or Enterprise Admins, should you want to more tightly control CA access (which you should).

windows server 2012 r2 certificate authority


At this point in the configuration there are no published templates. So in the following post we will configure a couple of templates, and I’ll show you how to delegate permissions so that other administrators can mint their own certificates. In this installment we’ve done the bulk of the subordinate CA configuration. At this point the CA is now functional, although no templates have been configured. So coming up in the next installment is, among other things, the process to configure templates and computer autoenrollment. Check out Part 3 here.

Are VMware vSphere 5.1 bugs behind us?

If anyone has been following the release of vSphere 5.1, you know it was not exactly a smooth launch. In fact, I would dare to call it a huge debacle. To me, it seems like it was rushed out the door without having components even beta tested, like the required SSO service. The original SSL certificate replacement instructions were 100% wrong, plus several components were very buggy. I really have no earthly idea how the code made it past internal quality assurance.

Clearly VMware recognized the 5.1.0 GA version had significant problems, and support calls probably clogged their phones. I know I personally spent many hours with the India support desk trying to fix SSL problems, with little success. So a few weeks after 5.1.0 GA, out came 5.1.0a. This helped, but still had a number of install problems and bugs. In late December 2012 they shipped 5.1.0b, which did zap many remaining installation bugs. Meantime, they also published a number of KB articles covering the right way to replace the certificates. Several articles have had revisions since their initial release.

So using the vSphere 5.1.0b media, refreshed VMware KB articles, and updating my own 15 blog articles, I finally got through a complete install without having to hack VMware scripts or do other undocumented steps. Easy? No. Quick? No. Vastly harder than it should be? Yes. Feel fragile? Yes.

Should you bet the stability of a large enterprise production environment on vSphere 5.1.0b? Only you can answer that for yourself, but personally this is the first release of vSphere that I won’t put into production. vSphere 5.0 U2 is very stable, and there aren’t any compelling features for my environment in 5.1 that I can’t wait to get rolled into vSphere v.Next due out in late 2013.

I’m also hopeful the new VMware CEO will put an emphasis on quality, and not push releases out the door that are not production ready. Just yesterday VMware announced some layoffs, spinning off a few products, and re-focusing on their core technology. I hope that includes re-focusing on quality releases and not just packing in new features to one-up Hyper-V.

Even if you don’t want to put 5.1 into production, I would strongly urge you to install it in a lab environment. Get used to the new web client, try out the new VDS features, etc. This will help you ramp up quicker on vSphere v.Next. Plus if you run into any bugs, open a support case so the future releases are more stable.

You can find Part 1 of my 15-part vCenter 5.1 installation series here. It was a lot of work, but I tried to incorporate my own lessons learned, reader feedback, and changes in VMware KB articles. In my home lab I now have a running vCenter 5.1.0b install, and I have yet to see any SSL problems or broken services.

If anyone follows my revamped guides and still has problems, please leave comments for the appropriate article. I can’t guarantee I’ll respond to all comments, but other readers may.

Creating a SSL certificate for Citrix Netscaler

A high availability VDI deployment, such as XenDesktop 5, demands that you use multiple servers to provide broker redundancy. As such, a load balancer such as the Citrix Netscaler comes in mighty handy. The NetScaler can also act as an ICA proxy between a trusted and untrusted network, such as the internet and your corporate network. Now that I’ve gotten XenDesktop 5 running in my lab, I wanted to see what it takes to configure the NetScaler Access Gateway feature to allow external inbound connections and serve up a nice VDI desktop.

As the configuration is somewhat complex, let’s start with the easy part, creating your own SSL certificate and importing it into the NetScaler. Now in the real world you’d need to use a trusted CA like Verisign, or your clients won’t trust the Access Gateway and the Citrix receiver will not launch. However, if you are in a lab or home environment you can use your own CA just to get the flavor how it works.

In my lab I’m using the latest NetScaler VPX release, which is v9.3 build 48.6.nc. First we need to use OpenSSL to create a private key, then a certificate request, convert the private key, then submit to my Microsoft CA, and finally import into the NetScaler. Figuring out this process was a bit easier than VMware makes it for importing certs into an ESXi host, so you have that going for you.

1. Login to the NetScaler and click on the SSL folder in the left pane.
2. Generate a private RSA key by clicking on Create RSA Key. Use a filename that is easily associated with the FQDN of the certificate and I would use a .key extension to denote it’s the private key. 2048 bits is the maximum keysize, so I’d go for that. Change the format to DER. Click on Create then Close.

3. On the NetScaler SSL page click on Create CSR. Type in a file name for the certificate request (I’d suggest a .req extension), then browse to the private key file you just created. In the Common Name field enter the FQDN you want your certificate to be bound to. Fill in the other information as needed. Click on Create then Close.

4. Back on the SSL page click on Manage Certificates then locate the REQ file, highlight it, then click on View. Copy the contents to the clipboard. Close the window.
5. Assuming you are using a Windows Server 2008 R2 CA, perform these steps:

  • Go to the certificate home page and click on Request a certificate.
  • Select Advanced certificate request.
  • Select Submit a certificate request by using a base-64-encoded….
  • Paste the certificate into the window and change the template to web server.
  • Download a DER encoded certificate (not the certificate chain) using a logical name like xd-contoso-net.cert.

6. Back on the NetScaler and open the SSL folder then click on Certificates.
7. Right click in the SSL window and select Install.
8. I would suggest the FQDN for the pair name, browse locally to the certificate file name, then browse on the appliance for the private key, and change the certificate format to DER.

9. Click on Install and hope that the certificates import successfully. Once the certificate imports, you should delete the certificate from wherever you downloaded it to on your workstation.

And there you have it! You’ve created your own private key, certificate request, generated a SSL certificate, then imported it to the NetScaler. The private key and public key file names are important, since the files are stored on the NetScaler and each certificate must have a unique name. You can repeat this process for any number of certificates, as needed. 

vCenter 4.1 U1 and FIPS encryption: Verify your IE Settings

During my regression testing of my vCenter 4.1 U1 installation instructions on Windows Server 2008 R2, I came across a problem that made me scratch my head. I was updating the vCenter SSL certificates, per my blog here. However, when I opened IE and tried to connect to the vCenter default home page would not come up. I got Internet Explorer cannot display the webpage.

OK I thought, maybe I goofed up the SSL certificates. I regenerated them, and nope, no good! The Windows Server 2008 R2 template that I’m using is locked down and has many security features enabled, including FIPS compliant encryption.

You can connect to vCenter with the vSphere client, but it appears the web services on port 443 are broken. For example, as I mentioned, the vCenter home page would not come up, the vCenter Service Status screen would not open, and performance graphs were also broken.

After additional research since my original post, the root cause appears to be the combination of two security settings: FIPS compliance, AND restricting what encryption algorithms IE is allowed to use.

The IE settings that cause the problem is the unchecking of TLS 1.0, as shown below.

This in combination with enabling FIPS on the server, as shown below, create a situation that doesn’t allow the TLS handshake to complete, so web based services that rely on IE settings break.
The lesson here is that if you have FIPS encryption enabled on the computer that you are accessing vCenter from, ensure your IE settings allow TLS 1.0. Normally TLS 1.0 is checked, so this won’t be a problem for most people. But if you are trying to enhance security by only allowing TLS 1.1 or higher, then you will run into issues.