anchor.diff:              enable_ssl: true
           ```
   
  -
   ##<a id="lb_and_gorouter_term"></a> Terminating SSL/TLS at the Load Balancer and Gorouter
   
  -In this configuration, CF establishes and terminates two TLS connections: one from the client to the load balancer, and another from the load balancer to the Gorouter. This configuration secures all traffic between the load balancer and the Gorouter.
  +In this configuration two TLS connections are established: one from the client to the load balancer, and another from the load balancer to the Gorouter. This configuration secures all traffic between the load balancer and the Gorouter.
   
   The following diagram illustrates communication between the client, load balancer, Gorouter and app.
   
   <%= image_tag("lb-and-router.png") %>
   
  -This option is less performant, but it does allow for multiple certificates to be used, meaning multiple domains can be verified when using HTTPS. 
  -
  -The advantages of securing the connection between your load balancer and Gorouter instances include:
  -
  -* A high level of security.
  -* The ability to secure a deployment that shares a load balancer with other deployments.
  -* The ability to manage certificates as part of your deployment manifest, which eliminates the need for out-of-band configuration of your load balancer.
  +This option is less performant, but it does allow for use of multiple certificates under certain circumstances. 
   
   ### <a id="cert_guidelines_lb_gorouter"></a> Certificate Guidelines
   
   In this deployment scenario, the following guidelines apply:
   
  -- On the Gorouter, you can use a SAN certificate, or a certificate for a single domain that the load balancer has been configured to trust. In the latter case, however, hostname validation must be disabled on the load balancer. 
  -- You can use a different SAN certificate on the Gorouter than the SAN certificate hosted on the load balancer, but these separate SAN certificates must be created for the same domains. Using different certificates enables having different keys. If the key for the certicate on the Gorouter is compromised, then the certificate on the load balancer is not at risk, and vice versa.
  -- Certificates for the <%=vars.product_short%> domains must be stored on the load balancer, and if hostname validation is enabled, on the Gorouter, which uses a single certificate. The certificate on the Gorouter only needs to be trusted by the load balancer, and the domain does not need to match the request as long as hostname verification is not enabled on the load balancer.
  +- Certificates for the <%=vars.product_short%> domains must be stored on the load balancer.
  +- On the Gorouter you can use a SAN certificate for all domains, or a standard certificate for a single domain that the load balancer has been configured to trust. In the latter case, however, hostname validation must be disabled on the load balancer, as the domain of the certificate served by the Gorouter will not match requests sent to applications on <%=vars.product_short%>. 
  +- If you are concerned about hosting a certificate key on the Gorouter, you can generate certificates for your load balancer for the same domains with a different key. If the key for the certicate on the Gorouter is compromised, then the certificate on the load balancer is not at risk, and vice versa.
  +
  +### <a id="hostname_verfication"></a> About Hostname Verification 
  +
  +Hostname verification between the load balancer and Gorouter is unnecessary when the load balancer is already configured with the Gorouter's IP address to correctly route the request. 
  +
  +If DNS resolution is being used by the load balancer to route requests to the Gorouters, then you should enable hostname verification.
   
   ### <a id="http_header_lb_gorouter"></a> About HTTP Header Forwarding
   
  -If you terminate SSL/TLS at your load balancer, then you must also configure the load balancer to append the `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers to the HTTP traffic it passes to the Gorouter.
  -
  -### <a id="hostname_verfication"></a> About Hostname Verification 
  -
  -Hostname verification between the load balancer and Gorouter is unnecessary when the load balancer is already configured with the Gorouter's IP address to correctly route the request. 
  -
  -If DNS resolution is being used by the load balancer to route requests to the Gorouters, then you should enable hostname verification.
  +If you terminate SSL/TLS at your load balancer, then you must also configure the load balancer to append the `X-Forwarded-For` and `X-Forwarded-Proto` HTTP headers to requests it sends to the Gorouter.
   
   ### <a id="lb-and-router"></a> Procedure: Load Balancer and Gorouter
   
   To enable this configuration, perform the following steps:
   
  -1. Add your certificate to your load balancer and configure its listening port. The procedures vary depending on your IaaS.
  +1. Add your certificates to your load balancer and configure its listening port. The procedures vary depending on your IaaS.
   1. Configure your load balancer to append the `X-Forwarded-For` and `X-Forwarded-Proto` headers to client requests.
   
       <br/>If the load balancer cannot be configured to provide the `X-Forwarded-For` header, the Gorouter will append it in requests forwarded to applications and system components, set to the IP address of the load balancer.
   
  -    <p class='note'><strong>Note</strong>: If the load balancer accepts unencrypted requests, it <strong>must</strong> provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it should not accept unencrypted requests. Otherwise, applications and platform system components that require encrypted client requests will accept unencrypted requests when they should not accept them.</p>
  +    <p class='note'><strong>Note</strong>: If the load balancer accepts unencrypted requests, it <strong>must</strong> provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it should not accept unencrypted requests. Otherwise, applications and platform system components that depend on the X-Forwarded-Proto header to reject unencrypted client requests will accept unencrypted requests.</p>
   
   1. Insert the certificate into your deployment manifest for the Gorouter:
       1. Use `bosh edit deployment` to open your release manifest for editing.
  
positive.code: ### <a id="cert_guidelines_gorouter"></a> Certificate Guidelines
  
  * The Gorouter currently only supports configuring a single HTTPS certificate.
  * The certificate on the Gorouter must be associated with the correct hostname so that HTTPS can validate the request.
  * Use a SAN certificate because <%=vars.product_short%> requires multiple wildcard domains.
  
  ### <a id="http_header_gorouter"></a>About HTTP Header Forwarding
  
  The Gorouter appends the `X-Forwarded-For` and `X-Forwarded-Proto` headers to requests forwarded to applications and platform system components. `X-Forwarded-For` is set to the IP address of the client, and `X-Forwarded-Proto` to the scheme of the client request.
  
  If you terminate TLS/SSL at the Gorouter only, you do not need to configure any additional HTTP header forwarding.
  
  ### <a id="pass-through"></a>Procedure: Gorouter Only
  
  
negative.code: 1. Configure your load balancer to pass through requests from the client to the Gorouter.
  1. Insert the certificate into your deployment manifest for the Gorouter:
      1. Use `bosh edit deployment` to open your release manifest for editing.
      1. Copy the contents of your certificate file into the `properties.router.ssl_cert` field and the contents of the private key file associated with your certificate into the `properties.router.ssl_key` field. Set `enable_ssl` to `true`.
  
          ```
          properties:
  