anchor.diff:  ----
   
   === Re-encryption Termination
  -Re-encryption is a type of edge termination where the client encrypts communication with a certificate, which is then re-encrypted with a separate certificate when the traffic reaches the destination; with the router using health checks to determine the authenticity of the host.
  -
  -Re-encryption termination is configured by setting `TLS.Termination` to reencrypt and providing the `CertificateFile`, `KeyFile`, the `CACertificateFile`, and a `DestinationCACertificateFile`. The edge certificates remain the same as in the edge termination use case. The `DestinationCACertificateFile` is used in order to validate the secure connection from the router to the destination (implemenation specific).
  +Re-encryption is a type of edge termination where the client encrypts communication with a certificate, which is then re-encrypted with a different certificate when the traffic reaches the destination; with the router using health checks to determine the authenticity of the host.
  +
  +Re-encryption termination is configured by setting `tls:termination` to `reencrypt` and specifying the `certificate`, `key`, and `caCertificate`, as well as the `destinationCACertificate`. The edge termination certificates remain the same as in the edge termination use case. The `destinationCaCertificate` is used in order to validate the secure connection from the router to the destination, and is specific to each implemenation:
   
   ----
   {
  
positive.code: }
  ----
  
  Note that while both secure and unsecure is possible with an OpenShift deployment, Red Hat recommends a secure routing service for a more secure deployment.
  
  == Securing Routes
  Creating a secure route to your pods can be accomplished by specifying the TLS Termination of the route and, optionally, providing certificates to use. As of writing, OpenShift beta1 TLS termination relies on SNI for serving custom certificates (in the reference HAProxy implementation). Any non-SNI traffic received on port 443 will have TLS terminated with a generic certificate. In the future, the ability to create custom frontends within the router will allow all traffic to serve custom certificates.
  
  There are three types of TLS termination:
  
  === Edge Termination
  Edge termination means that TLS termination occurs prior to traffic reaching the destination. TLS certificates are served by the frontend of the router.
  
  Edge termination is configured by setting `TLS.Termination` to edge on your route and by specifying the `CACertificatFile`, `CertificateFile` and `KeyFile`.
  
  ----
  {
  
negative.code: toc::[]
  
  == Overview
  Routers provide external DNS mapping and load balancing to services over protocols that pass distinguishing information directly to the router (HTTP, HTTPS, and TLS with SNI). Routers subscribe to a configuration and automatically update themselves with any changes, and may be containerized or virtual (converting those changes to API calls to a system like an F5).
  
  Other capabilities exist to load-balance a service within a cluster. These services are exposed via a configurable link relation between different services, and ensure a set of services can be available. Deployments may choose to use these services as local proxies for each host, or to reuse the shared routing infrastructure.
  
  While configuring a router is up to the OpenShift administrator, setting the route types of each individual application is up to the application developer.
  
  == Route Types
  Routes can be either secure or unsecure. Secure routes provide the ability to use different types of TLS termination to serve certificates to the client. To create a secure route, specify the TLS termination of the route in a json file.
  
  
  .An unsecure route:
  ====
  
  ----
  {
  