anchor.diff:              enable_ssl: true
           ```
   
  -##<a id="lb-and-router"></a> Terminate TLS at Load Balancer and Router
  +
  +##<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.
  +
  +The following diagram illustrates communication between the client, load balancer, Gorouter and app.
  +
   <%= image_tag("lb-and-router.png") %>
   
  -<p class='note'><strong>Note</strong>: Hostname verification between the load balancer and CF router is unnecessary when the load balancer is already configured with the CF router's IP address to correctly route the request. If DNS resolution is being used by the load balancer to route requests to the CF routers, you should enable hostname verification.</p>
  -
  -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 CF router. This option is less performant, but it does allow for multiple certificates to be used, meaning multiple domains can be verified when using HTTPS. Certificates for the CF domains must be stored on the load balancer and, if hostname validation is enabled, on the CF router (using a single certificate). The certificate on the CF router 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.
  -
  -This configuration secures all traffic between the load balancer and the router.
  -
  -<p class="note"><strong>Note</strong>: If your CF deployment uses a self-signed certificate, the client needs to install only the certificate stored on the load balancer.</p>
  +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.
  +
  +### <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.
  +
  +### <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.
  +
  +### <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. 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 CF router 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 shouldn't.</p>
  -
  -1. Insert the certificate into your deployment manifest for the CF router:
  +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>
  +
  +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`.
   
  
positive.code: 
  <strong><%= modified_date %></strong>
  
  This topic describes how to secure traffic into your Cloud Foundry (CF) deployment with SSL/TLS certificates. You can configure your deployment to specify where to terminate TLS depending on your needs. 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 router.
  
  The advantages of securing the connection between your load balancer and router 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.
  
  For more information about the features of HTTP routing handled by the Cloud Foundry router, see the [HTTP Routing](../concepts/http-routing.html) topic.
  
  ##<a id="requirements"></a> Requirements
  
  * You must obtain a SSL/TLS certificate. In a production environment, use a signed SSL/TLS certificate from a known certificate authority (CA). In a development or testing environment, you may use a self-signed certificate generated with `openssl` or a similar tool.
  * The CF router only supports HTTP requests. Whatever configuration you choose for securing traffic, it must result in the CF router receiving HTTP requests.
  * The CF router currently only supports configuring a single HTTPS certificate. [Subject Alternative Name](https://tools.ietf.org/html/rfc5280#section-4.2.1.6), an X.509 extension, can be used to associate multiple domains, including wildcard domains, to a single certificate.
  
  ##<a id="pass-through"></a> Terminate TLS at Router Only
  <p class='note'><strong>Note</strong>: This is the recommended approach.</p>
  <%= image_tag("pass-through.png") %>
  
  In this configuration, the load balancer does not terminate TLS for CF domains at all. Instead, it passes through the underlying TCP connection to the router. This is the more performant option, establishing and terminating a single TLS connection. The certificate on the router must be associated with the correct hostname so that HTTPS can validate the request, and signed by a trusted CA.
  
  Traffic between the load balancer and the router is encrypted only if the client request is encrypted.
  
  The router 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.
  
  To enable this configuration, perform the following steps:
  
  1. Configure your load balancer to pass through requests from the client to the CF router.
  1. Insert the certificate into your deployment manifest for the CF router:
      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:
  
negative.code:               -----END RSA PRIVATE KEY-----
              enable_ssl: true
          ```
  1. If your CF deployment uses a self-signed certificate, then the client only needs to install the certificate stored on the load balancer.
  
  
  ##<a id="lb_term"></a> Terminating SSL/TLS at the Load Balancer Only
  
  In this configuration, your load balancer terminates TLS, and passes unencrypted traffic to the Gorouter, which routes it to your app. Traffic between the load balancer and the Gorouter is not encrypted.
  
  This option is recommended if wildcard certificates are not supported for some or all of your domains.
  
  The following diagram illustrates communication between the client, load balancer, Gorouter and app.
  
  <%= image_tag("lb.png") %>
  
  ### <a id="cert_guidelines_lb"></a> Certificate Guidelines
  
  You can use multiple certificates on the load balancer if the load balancer supports multiple VIPs or SNI. Otherwise, use a SAN certificate.
  
  ### <a id="http_header_lb"></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="lb"></a> Procedure: Load Balancer Only
  
  To enable this configuration, you must perform the following steps:
  
  1. Configure your load balancer to append the `X-Forwarded-For` and `X-Forwarded-Proto` headers to client requests.
      * If the load balancer cannot be configured to provide the `X-Forwarded-For` header, the Gorouter appends it in requests forwarded to applications and system components, set to the IP address of the load balancer.
      *  <strong>Important:</strong> Configure the load balancer to forward the `X-Forwarded-Proto` header. If you fail to configure this forwarding, requests to some applications and system components result in redirect loops, as some requests determined to be unencrypted are redirected to HTTPS.
  
  1. Add your certificate or certificates to your load balancer and configure its listening port. The procedures vary depending on your IaaS.
  
  