There are many reasons to blog. As with many of us, we have many roles. Along with being our primary VMware guy, I also have the fantastic pleasure of being our load balancer guy. We currently have 12 Citrix Netscalers (6 MPX physical appliances and 6 VPX virtual appliances). We are one of the few people I know that uses Netscaler without a shred of XenApp or XenDesktop (although we do load balance our Horizon VDI environment with them!)
Anyway, I would like to talk about a massive project that we have going on. We are in the middle of a re-branding effort at work. Changing a domain name is no small task. Being a higher-education organization, we do not get our names from a typical public registrar as most commercial organizations do. Instead, we go through Educause for our domain names. They have a policy that all educational organizations are limited to a single domain name. Educause will give you 6 months to move from one name to another, and if you ask nicely, they may give you a 6 month extension.
For the purposes of this blog, I will go over the different strategies you can use to transition from one name to another as it relates to terminating SSL on a Citrix Netscaler load balancer (including the strategies we have chosen).
When the project was announced, I had a single goal. I wanted to abstract my responsibilities away from the application teams. My maintenance operations should be completed in advance of the application teams, and the only dependency would be their dependency on my work getting done beforehand. The last thing I wanted to do was to be involved in the application cutover, and be forced to participate in all weekend cutovers that they have scheduled. The Load Balancer guy ends up having a major role with practically every on-premises application when you rename your domain name!
For the most part, there are four different cutover strategies as it relates to SSL certificates.
- Single name to Single name certificate — (oldname.com to newname.com)
- Single name to SAN (Subject Alternative Name) certificate — (oldname.com to SAN cert with oldname.com & newname.com)
- Single wildcard to single wildcard — (*.oldname.com to *.newname.com)
- Single wildcard to multiple wildcard using Server Name Indication — (*.oldname.com to leveraging *.oldname.com and *.newname.com simultaneously)
Single name to single name certificate
This strategy means you will be creating a new CSR (Certificate Signing Request), obtaining the cert, adding it to the load balancer, and waiting for the application team to add support for the new namespace in the application. When they cut over to the new name, you need to replace the SSL certificate on your VIP (or content-switching / load balanced vserver object). Since you typically can only have a single certificate bound to your vserver, it needs to be changed with the application team. This was not something I wanted to do as per my previous point. It might be a bit easier if you stand up a second IP address, create a new “A” record for the new name, point to the same back-end services, and obtain a new SSL certificate for the new name. That way, you don’t have to be involved as much, but you may need to get a bunch of new firewall rules created, and there will be cleanup to decommission the old load balancer rules, and firewall rules for the old IP address. Instead, I would opt for:
Single name to SAN (Subject Alternative Name) certificate
This strategy means you need to create a new SSL certificate that includes the old name, and the new name, all in one certificate. SAN certificates are super handy for many environments, but are a bit more complicated to configure. Once the new cert is installed, the application owners can cut over the application to the new name without SSL load balancer work needing to be done. The negative for this strategy, is once the new certificate is generated, the old single-name certificate needs to be revoked because it is one of the subject alternative names in the new cert. We are given a 30 day grace period before the old cert is invalid. We need to make sure the cert installed before the 30 day period is up.
I will be covering the process of how to create a CSR for a SAN certificate on a Netscaler load balancer in the next post.
What if you have an application where you have dozens of possible subdomains for the same root domain? All of these domains may resolve a small subset or single IP address. In that case, you may want to issue a wildcard certificate. Two possibilities for managing a domain name change using a wildcard certificate are below.
Single wildcard to single wildcard
Many of our applications have different application server groups for each campus instance of the application. Each campus has their own branded instance with their own sub-domain name. Content switching policies direct users to the proper application servers based on what URL they have entered. This is where as I said, this is where wildcard certificates come into play. By default, content switching vservers will only allow a single SSL certificate. From what we have seen, there is no such thing as a wildcard SAN certificate (multiple wildcards on a single certificate). Therefore, this option (once again) requires the wildcard to be changed out in conjunction with the application owners’ name cutover. The challenge is, if you have 37 campuses as we do (and 37 instances of an application), the app owners cannot flip a switch 37 times in short order. The SSL certificate replacement is immediate, so there will be a period of time where users will get a certificate error. The answer to this issue is in the next section.
Single wildcard to multiple wildcard (using Server Name Indication)
If you want to put multiple wildcard certs on a single content switching vserver, you must use SNI or Server Name Indication. SNI is a neat little trick that allows you go from a single wildcard bound to a content-switching vserver (legacy domain name), to multiple wildcards bound to a content-switching-vserver (legacy domain name plus new domain name), and then back to a single wildcard (final configuration using the new domain name). Since the certificates are bound separately, you must contend with separate expiration dates. I will also go further into how you configure SNI on a Netscaler with multiple wildcard certificates in a follow-up post.
I plan to post two follow up articles, one on the process required to issue the above cert types on a Netscaler, and content switching policy strategies in handling a domain name change.