anchor.diff:                -----END RSA PRIVATE KEY-----
               enable_ssl: true
           ```
  -
  -
  -##<a id="lb"></a> Terminate TLS at Load Balancer Only
  +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") %>
   
  -In this configuration, your load balancer terminates TLS, and passes unencrypted traffic to the router, which routes it to your app. Traffic between the load balancer and the router is not encrypted.
  +### <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.
  -
  -    <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>: When terminating TLS at the load balancer only, the load balancer <strong>must</strong> be configured to forward the X-Forwarded-Proto header. Otherwise requests to some applications and system components will result in redirect loops, as they will redirect requests determined to be unencrypted to HTTPS.</p>
  -
  -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.
  +    * 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.
  +
  
positive.code:             enable_ssl: true
          ```
  
  ##<a id="lb-and-router"></a> Terminate TLS at Load Balancer and Router
  <%= 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>
  
  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. 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`.
  
  
negative.code: 
  <strong><%= modified_date %></strong>
  
  This topic describes the options for securing HTTP traffic into your <%=vars.product_full%> <%=vars.product_abbr%> deployment with SSL/TLS certificates. You can configure the location where your deployment terminates TLS depending on your needs and certificate restrictions. 
  
  <%=vars.ssl_config%>
  
  ## <a id="protocol_support"></a> Protocol Support
  
  Gorouter supports HTTP/HTTPS requests only. For more information on features supported by the Gorouter, see the [HTTP Routing](../concepts/http-routing.html) topic.
  
  To secure non-HTTP traffic, terminate TLS at your load balancer or at the application. See [TCP Routing](enabling-tcp-routing.html) for details.
  
  ##<a id="ssl_options"></a> SSL/TLS Termination Options
  
  There are three options for terminating SSL/TLS for HTTP traffic. You can terminate TLS at the Gorouter, your load balancer, or at both. 
  
  The following table summarizes SSL/TLS termination options and which option to choose for your deployment.
  
  <table border="1" class="nice">
  <tr>
    <th>If the following applies to you:</th>
    <th>Then configure SSL/TLS termination at:</th>
    <th>Related Configuration Procedure</th>
    </tr>
    <tr>
    <td><ul><li>You want the most performant and recommended option, and </li>
    <li>You can use a single SAN certificate for all system and application domains for your deployment.</li>
    </ul></td>
    <td>
    Gorouter only
    </td>
    <td> <%=vars.ssl_gorouter_link%>
    </td>
    <tr>
    <td><ul><li>You cannot use a single SAN certificate for all system and application domains for your deployment, or</li>
    <li>You require Extended Validation (EV) certificates.</li>
    </ul>
    </td>
    <td>Load Balancer only
    </td>
    <td> <%=vars.ssl_lb_link%>
    </td>
    </tr>
    <tr>
    <td><ul><li>You want a higher level of security, and</li>
    <li>You do not mind a slightly less performant deployment, and</li>
    <li>You can use a single SAN certificate on the Gorouter, either for all system and application domains (but with a different key than for the same certs hosted on your load balancer) or for a single domain (but with hostname verification disabled on the load balancer).</li>
    </td>
    <td>
     Load Balancer and Gorouter
    </td>
    <td> <%=vars.ssl_lb_gorouter_link%>
    </td>
    </tr>
  </tr>
  
    
    </table>
       
  
  ## <a id="certtypes"></a> Certificate Requirements
  
  The following requirements apply to the certificates you use to secure traffic into <%=vars.product_short%>
  
  * In a production environment, use a signed SSL/TLS certificate (trusted) from a known certificate authority (CA).
  * In a development or testing environment, you can use a trusted CA certificate or a self-signed certificate generated with `openssl` or a similar tool.
  * The Gorouter currently only supports configuring a single HTTPS certificate. The certificate on the Gorouter must be associated with all the domains it may receive requests for so that HTTPS can validate the request. To associate multiple domains to a single certificate, including wildcard domains, use [Subject Alternative Name (SAN)](https://tools.ietf.org/html/rfc5280#section-4.2.1.6), an X.509 extension.
  * If wildcard certificates are not supported for some or all of your domains, then terminate TLS at your load balancer.
  * If you cannot use a SAN certificate, terminate TLS at your load balancer.
  * Extended Validation (EV) certs support multiple hostnames, like SAN, but do not support wildcards. For this reason, if EV certs are required, then terminate TLS at the load balancer only
  * If you must terminate TLS at your load balancer, you may optionally secure requests from the load balancer to the Gorouter by terminating TLS at the Gorouter also. To accomplish this without using a SAN cert on the Gorouter, you will have to disable hostname validation on the load balancer, as the domain in the certificate hosted by the Gorouter will not match requests forwarded to it for applications on <%=vars.product_full%> by the load balancer.
  
  ##<a id="gorouter_term"></a>Terminating SSL/TLS at the Gorouter Only
  
  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 Gorouter. 
  
  This option is the recommended and more performant option, establishing and terminating a single TLS connection. 
  
  The following diagram illustrates communication between the client, load balancer, Gorouter and app.
  
  <%= image_tag("pass-through.png") %>
  
  Traffic between the load balancer and the Gorouter is encrypted only if the client request is encrypted.
  
  ### <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
  
  To enable this configuration, perform the following steps:
  
  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.Gorouter.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:
  