Merge pull request #576 from Ashex/certificate-arn

Load Balancer Tip on retaining IAM Server Certificate ARN

README.md

@@ -1051,6 +1051,13 @@ Load Balancers
 -	**Scaling:** CLBs and ALBs can scale to very high throughput, but scaling up is not instantaneous. If you’re expecting to be hit with a lot of traffic suddenly, it can make sense to load test them so they scale up in advance. You can also [contact Amazon](http://aws.amazon.com/articles/1636185810492479) and have them “pre-warm” the load balancer.
 -	**Client IPs:** In general, if servers want to know true client IP addresses, load balancers must forward this information somehow. CLBs add the standard [X-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For) header. When using an CLB as an HTTP load balancer, it’s possible to get the client’s IP address from this.
 -	**Using load balancers when deploying:** One common pattern is to swap instances in the load balancer after spinning up a new stack with your latest version, keep old stack running for one or two hours, and either flip back to old stack in case of problems or tear it down.
+-   **Rotating Certificates while retaining ARN:** Rotating IAM Server Certificates can be difficult as the standard practice is to upload a new one then update all resources with the new ARN. You can however retain the same ARN using the `update-certificate` call with the following process:
+  1. Upload a new IAM Server Certificate with a unique name (e.g fuzzy.com.new)
+  2. Rename the existing IAM Server Certificate (e.g fuzzy.com to fuzzy.com.expired)
+  3. Rename the new IAM Server Certificate to the name of the previously existing certificate (e.g fuzzy.com.new to fuzzy.com)
+  4. Jiggle the CLB/ALB Listener to pick up the change:
+      * ALB: Invoke modify-listener with the existing details for the ALB Listener
+	  * CLB: Invoke create-load-balancer-listeners with the existing details for the CLB listener
 
 ### Load Balancer Gotchas and Limitations