SSL Certs for IIS with PFX once and for all - SSL and IIS Explained

The problem is more common than dirt but the solutions provided are so often entirely incorrect and obscure and that's likely because the "Linux and Apache" folks are trying to use their standard approach with MS platforms that like to do their own thing.

Here's what you need to understand:

CSR - Certificate Signing Request: A CSR is how you ask for a certificate and provides things like your identify, the use, etc..

KEY - Private Key: When someone uses the public key that you share with the world (like that which your web server will give the client and they will use to encrypt traffic), your possession of the private key is how you prove (as a web site) that you are master. You encrypt using your private key and the client decrypts with your public key. ANYONE can have your public key and thus anyone can decrypt but since you are the only one with a private key, it is guaranteed (when you control that key correctly) that if the public key works, traffic must have come from you. Similarly, anything encrypted with your public key can ONLY be decrypted using your private key.

CER/CRT/CERT/CERTIFICATE - Public Key: See KEY explanation

PFX: Along comes microsoft and their proprietary way of doing things and the confusion that follows. IIS expects a PFX but the format has nothing to do with the standards world of PKI, keys and certs really. So how do you give them a PFX that includes the private key (needed to encrypted/decrypt your web traffic)? The intended way is for you to generate the CSR using IIS then give that CSR to your CA (internal or public) then get a key back based on the private key known by the creator of the CSR (IIS). This is where things are "all wrong" in the public CA business (from the perspective of us using IIS but really, they have it right). Most likely you created the CSR using your CA or the company reselling for them (cheapssl, gogetssl, etc..). When you do this, they give you a private key to keep safe and a public key to use but IIS/Windows has no concept of the private key so you're dead in the water from the start.


The solution:

Use IIS "Server Certificates" UI to "Generate Certificate Request" (the details of this request are out of the scope of this article but those details are critical). This will give you a CSR prepped for IIS. You then give that CSR to your CA and ask for a certificate. Then you take the CER/CRT file they give you, go back to IIS, "Complete Certificate Request" in the same place you generated the request. It may ask for a .CER and you might have a .CRT. They are the same thing. Just change the extension or use the *.* extension drop-down to select your .CRT. Now provide a proper "friendly name" (*.yourdomain.com, yourdomain.com, foo.yourdomain.com, etc..) THIS IS IMPORTANT! This MUST match what you setup the CSR for and what your CA provided you. If you asked for a wildcard, your CA must have approved and generated a wildcard and you must use the same. If your CSR was generated for foo.yourdomain.com, you MUST provide the same at this step.

Now select the PERSONAL store (No, not webhost). This will import your CRT in the personal store where it can be associated with the private key generated by IIS when it created the CSR. THIS IS WHERE ALL THE PROBLEMS COME FROM. This is what causes SO many headaches. The CRT you got from your CA and the KEY they gave you are useless here unless you do as others might suggest and go play around with other tools like openssl (which can work but why bother when you can do it the way IIS intended?)

Now you should see your cert in the server certificates list and if you open it, you should see something like, "You have a private key that corresponds to this certificate".

Now if you can use the Export function (IIS 8 provides this in the same place as the "request" and "complete request" links) or use the Certificate MMC then navigate to the personal store and export from there to the PFX format. You need to provide a strong password to protect this file because it will have the entire certificate chain AND your private key. In other words, this PFX has the keys to the entire "domain" (speaking figuratively).

Chances are that you don't even need the PFX now because you already have the certificate inside IIS but if you're using the centralized certificate store like I am, you do AND the file name is critical. For wildcard certs, the name MUST be _.yourdomain.com.pfx (assuming your request was for *.yourdomain.com). If you asked for www.somedomain.org, then the filename must be www.somedomain.org.pfx because this is how SNI and centralized SSL store will look for the right one.


In summary, the easy way to install an SSL cert into IIS:

1. Generate your CSR using IIS
2. Provide that CSR to your CA
3. "Complete Request" using the CER/CRT you get back from the CA
4. [optional] Export to PFX and protect with a strong password
5. Live long and encrypt

Update (20191201): Even today, I am using this post as I have to renew SSL for a stack that lives both on IIS and Node.js. Because of this, I also need the private key file so if you've done step #4 above and need a .key also, the following might save you some googling. Be sure to protect your .key file when you do this though!

`openssl pkcs12 -in exported.pfx -nocerts -out key.pem -nodes`

then

`openssl rsa -in key.pem -out server.key`

Now you you can use server.key and the cer/crt you were provided.

My first experience with VMware vCHS - Part 2 - vCloud Connector

This is the 2nd in a vCHS series. You can find the previous entry HERE.

OnPrem - vCloud Connector (general label for a collection of systems and configuration)

If you don't know what vCloud is or about the vConnector, right now all you need to know is that you can't do actual migrations (it creates vApp templates from powered down VMs) and the only other thing is really useful for are stretch migrations (a vShield networking trick that are only useful in some very rare situations.

VCC does NOT allow you to use the vSphere client to manage vCHS any more than you can do on the web (for the most part, it just gives you a window to the web interface and does some back-end management that you can also initiate from the web).

• vCloud Connector Server - Provided as a zip containing an OVF that can be easily added to any host onPrem. Once you've installed, visit https://assignedip:5480/ (port 5480 is a theme so learn it). Once you've configured networking, set the time-zone and changed the password, contine to the Node which is the same process.
• vCloud Connector Node- Provided as a zip containing an OVF that can be easily added to any host onPrem. Once you've installed, visit https://assignedip:5480/
• Once you've installed the node and done the same basic config (IP/Time-zone/Password), you need to go to the Node/Cloud menu and register your vCenter to the node (the node manages vCenter and the VCCS manages the node).
• Next you can go back to the VCCS and "register the node".
• Now we want to register the vCHS node to your VCCS.
• This is what allows you to use your vCenter to manage onPrem and vCHS together (and any other nodes you register). This is where I hit some frustrating resistance.
• To register vCHS node you need the Node URL (given to me in my onboarding email), VCD Org Name (not given to me and I had to deduce that it was provided in vCHS vCloud Director. It is the unique ID at the very top of the page, next to the navigation arrows. For me it was MXXXXXXX-XXX. You also need a username and password which you might think should be the same you log into the vCHS portal with but it apparently is not.
• After a few failed attempts, I was able to navigate to the vCloud Director, My Cloud, Logs, Events and see the failed attempts. Despite multiple emails and a phone call to vCHS support, I presently do not have the credentials I need so I'm stuck with the connector for now. More to come.....
• UPDATE: After speaking with vCHS support, it sounds like my credentials are out of sync in one of their DBs and I was doing everything right. Now I wait for them to tell me it's fixed.
• The solution came fairly quickly (less than 2 hours) and I had my vCHS node registered with VCCS.

If you have questions, please feel free to ask in comments. This was someone brief but it's because once it's working, it's really very straight-forward until/unless you try a stretch deploy (which I haven't).

Next will be an entry on vCHS networking.

My first experience with VMware vCHS - Part 1 - Setup and IPSEC

Prologue to vCHS Migration

I've decided to do a few articles regarding my migration to VMware vCHS (cloud hosting) solution and this is the 1st in the series.

I've had a few significant technical issues but the support has been as good as I can imagine. Last night I even met up with the specialty sales-rep assigned to my account and we spent nearly 3 hours talking over dinner about things in general and my project. VMware is not only doing more than I could hope to get me up and running but they're also looking at how they can help me through their "success stories" to help promote our business in a mutually beneficial manner which is wonderful because after 10 years of seeing 20%+ growth per year, we're likely going to explode this year leaving those gains in the dust and any help they provide will only strengthen our growth.

By the way, the "Customer Success Team" isn't a hollow catch-phrase. It reminds me of my experience as a consumer with American Express. They JUMP every time I need help. We have scheduled 2 hours calls (that we 3 hours) where they literally sat on the phone with me to walk through issues and wait for me to learn and question them AND did it with a wonderful attitude (sincerely eager to help).

In summary, the migration has been rough, but when do they go smooth? That said, I can't imagine a better infrastructure than they're giving me and their support is the best I've seen for any product/service anywhere save perhaps for high-end auto purchase experiences I've had.

I would HIGHLY recommend vCHS to anyone that needs a rock-solid, highly flexible hosting solution that covers everything from end-end.

At the moment we have 3 units of the VPS solution (they have dedicated and shared, VPS is the shared solution) which includes 15GHz dedicated CPU (you really can't talk cores or speed with the way they work), 30Ghz Burst, 60GB Ram (dedicated) and 2TB of SAN storage that is SSD cached and I'm constantly seeing 150MB-250MB/s with <2ms latency and my SQL Server is running as fast as it was locally with dual-quad xeons on a 8-disk RAID 10 over 15kSAS drives.

My first experience with VMware vCHS - Part1 - Setup and IPSEC

My present hosting provider hasn't been a pleasant experience. I seem to have some bad luck this way. My last experience was with RackSpace who has very good service in so many ways, but I found out the hard way that their security is severely lacking and when they make a mistake that cost me $10,000's, they had NO interest in taking responsibility and I'm not big on law suits so I dealt with the months (almost years) of heartache, moved on and tried Central Host (the hosting division of 8x8 which has since been bought up by Black Lotus.

My experience with 8x8 was a nightmare and I'm still feeling the pain as Black Lotus does their best to clean up the data center I'm in. They've also made amazing efforts to make things right with me but I'll leave that for my other blog. In the end, they offered me an incredible deal (~$2,000/mo for dedicated virtual hosts, 6-core HT, 3.5Ghz Xeon CPUs, 32GB ram, 2TB SATA RAID with 200GB SSD caching, 24 IPS and each of 2 hosts were at different data-centers) but they use App-Assure (Xen and/or Kvm) and I'm a Vmware guy interested in uptime and performance more than raw performance and didn't want to learn new systems either. VCenter is amazing and I know how to keep my business running with it so I went with vCHS. I also appreciate the way vCHS scales compared to typical virtual hosting solutions. I don't have to worry about "hosts".

The way the actual provisioning went was very straight forward. I got an email once the contract was signed and they told me provisioning had started. Once provisioning was done, I got an email with vCloud login and password setup links. I set my password, logged in, and headed over to the edge network configuration interface in the vCloud Director portal (the things they haven't made more simple and put into the vCHS portal and accessed through a full-blow vCloud Director instance which I prefer anyway not having really taken to the vSphere Web interface as it is).

Since I use pfSense (presently 2.1 and everything below assumes that) at all my other data-centers, I did a quick search and ended up using THIS guide as a reference to catch the nuances of their IPSec implementation (main/aggressive, which encryption he got working, etc..)

From there I went to my only gateway, edge gateway services, enabled VPN, setup the public IP, then added my tunnel (they combine phase 1 and phase 2 into a single UI). I quickly found that they use main and not aggressive which I should have caught from the tutorial I found. This is where I had my first issue. vCloud directory gateway status shows "System Alerts" with a red icon that was clickable and I wanted to see what it had to say so I clicked it and watched the entire UI refresh. I tried this a few times before giving up. I'm guessing it's a popup blocker issue at this point but since the directory comes up in a new window with no address bar and uses Flash (grr, WHY would they do that with such a new system???!!!) so there was no way to tell quickly and so I gave up there and went back to pfSense logs to see how things are going.

As so often is the case when doing IPSEC between pfSense and anything other than pfSense, I had to figure out what IPSEC standards they use. Here's what I found and I hope it saves someone some time. It's taken me years to get to a point where this doesn't become an all-night project:

If you know what you're doing and want to skim the settings, just know that even though vCHS asks for "Peer ID", it only supports Main mode which only supports IPs are IDs so Peer ID MUST be the remote gateway IP. This stinks for those of us trying to use more advanced methods to get around dynamic IPs. Really, "Peer ID" should read "Peer IP" and the only reason you have to provide both it AND "Peer IP" (which should read "Peer Gateway IP") is because they do support NAT-T.

Once I realized my mistake with the Peer ID, I had to delete the entry and create a new one then got an error about "Configuring Edge Gateway Services". I refreshed and it disappeared so I figured it was a fluke until I was seeing the same errors about IDs and when I check vCHS, the settings were back to the first entry so I deleted and tried again tripple-checking using the settings below and THEN I got a connection (I already had phase 2 setup. See below Phase 1 for settings). Once everything was working, my IPSec log had only 3 entries before a full connection (since there were so few options or advanced features being used).

Phase 1

• Main Mode
• Name: Anything descriptive you like
• Description: More descriptive stuff you like
• Enable this VPN: checked (default)
• Establish VPN to: "a remote network"
• Local Endpoint: (predefined external IP endpoint at the vCHS end)
• Local ID: The vCHS public IP assigned to the local endpoint (pfsense: Remote Gateway and Peer identifier)
• Peer ID: The IP of the remote gateway (pfsense: My identifier, My IP Address)
• Peer IP: The IP of the remote gateway
• Encryption protocol: AES-256 (pfsense: same for Phase 1 Encryption algorithm)
• pfsense-Hash: SHA1
• pfsense-DH Key Group: 2 (1024 bit)
• pfsense-Lifetime: 28800
• pfsense-Nat-T: Disable (if you need it, enable and update the Local ID on vCHS accordingly)

Phase 2 (pfsense)

• Mode: Tunner IPv4
• Local Network: Lan subnet
• Remote Network: CIDR format for remote subnet (ex. 192.168.110.0/24)
• Protocol: ESP
• Encryption: AES 256 (they only appear to support AES at this time)
• Hash: SHA1
• PDF key group: 2 (1024bit) (they support off also)