You can secure HTTP traffic into your TAS for VMs deployment with TLS certificates. This article describes how. You can also configure the location where your deployment stops TLS depending on your needs and certificate restrictions.

Protocol support

The Gorouter supports HTTP/HTTPS requests only. For more information about features supported by the Gorouter, see HTTP Routing.

You can force HTTPS-only connections by activating HSTS on HAProxy. For more information, see the Secure Apps Domain with HAProxy section of the Securing System and App Endpoints topic.

To secure non-HTTP traffic over TCP routing, terminate TLS at your load balancer or at the app. For more information, see Enabling TCP Routing.

TLS termination options for HTTP routing

There are several options for terminating TLS for HTTP traffic. You can terminate TLS at the Gorouter, your load balancer, or both.

The following table summarizes TLS termination options and which option to choose for your deployment.

Note: To ensure traffic is sent to the platform securely, VMware recommends as a minimum that you terminate TLS at the Gorouter. You can optionally terminate TLS at the load balancer.

If the following applies to you: Then configure TLS termination at: Related topic and configuration procedure
  • You want the optimum balance of performance and security, and
  • You want to make minimum changes to your load balancer, or
  • You are deploying TAS for VMs to AWS. For information about AWS limitations, see TLS Cipher Suite Support by AWS ELBs.
 Gorouter only Terminating TLS at the Gorouter Only
  • You require TLS termination at a load balancer, or
  • You want the highest level of security, and
  • You do not mind a slightly less performant deployment.
 Load Balancer and Gorouter Terminating TLS at the Load Balancer and Gorouter
  • You require TLS termination at a load balancer, and
  • You prefer unencrypted traffic between the Load Balancer and the Gorouter.
 Load Balancer only Terminating TLS at the Load Balancer Only
Optionally, if you are deploying HAProxy, and Then in addition, terminate SSL/TLS at: Related topic and configuration procedure
  • You would like to secure traffic to the HAProxy.
 HAProxy Terminating SSL/TLS at HAProxy

Certificate requirements

The following requirements apply to the certificates you use to secure traffic into TAS for VMs:

  • You must obtain at least one TLS certificate for your environment.

    • In a production environment, use a signed 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. You can generate a self-signed certificate with openssl or a similar tool.

    Note: Alternately, you can use the TAS for VMs Ops Manager interface to generate a certificate for you. Certificates generated in TAS for VMs are signed by the Ops Manager Certificate Authority. They are not technically self-signed, but they are sometimes referred to as "self-signed certificates" in the Ops Manager UI and throughout this documentation. For more information, see the Multiple certificates

    In order to support custom domains on TAS for VMs, an operator has to configure the Gorouter with a certificate that represents the domain. VMware recommends that operators add a new certificate instead of reissuing a single certificate when adding TLS support for an additional domain. Using multiple certificates provides a security benefit in that it prevents clients from discovering all the custom domains of apps running on a TAS for VMs platform.

    The Gorouter supports SNI and can be configured with multiple certificates, each which may optionally include wildcard and alternative names. The Gorouter uses SNI to determine the correct certificate to present in a TLS handshake. It requires clients to support the SNI protocol by sending a server name outside the encrypted request payload. For clients that do not support SNI, the Gorouter presents a default certificate. The default is the first certificate keypair in the Gorouter’s configuration.

    The Gorouter decides which certificate to provide in the TLS handshake as follows:

    • If a client provides an SNI header with a ServerName that matches to a configured certificate keypair, the Gorouter returns the matching certificate.

    • If a client provides an SNI header with a ServerName that does not match a configured certificate keypair, the Gorouter returns the default certificate.

    The first certificate keypair listed is used as the default.

    The Gorouter supports both RSA and ECDSA certificates in PEM encoding. In the case that a certificate chain is required, the order should be as follows: primary certificate, intermediate certificate, then root certificate.

    How to configure multiple certificate keypairs

    To configure multiple HTTPS certificate keypairs for TAS for VMs, add each keypair along with a meaningful name in the applicable Certificates and private keys for the Gorouter and HAProxy fields of the Networking pane in TAS for VMs. For more information, see Configure Networking in Configuring TAS for VMs.

    In TAS for VMs, multiple certificates configured for the Gorouter are also configured for HAProxy.

    TLS cipher suite support

    Some TAS for VMs components like the Gorouter support additional TLS cipher suites to accommodate older clients. As a security best practice, only configure the TLS cipher suites that you need for your deployment.

    Default Gorouter cipher suites

    By default, the Gorouter supports the following TLS cipher suites:

    TLS Version RFC OpenSSL
    1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
    1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384
    1.3 TLS_AES_128_GCM_SHA256 TLS_AES_128_GCM_SHA256
    1.3 TLS_AES_256_GCM_SHA384 TLS_AES_256_GCM_SHA384
    1.3 TLS_CHACHA20_POLY1305_SHA256 -

    You can override the default cipher suites in the Networking pane of the TAS for VMs tile. For more information about using custom SSL ciphers, see Gorouter Only or Load Balancer and Gorouter.

    TLS cipher suite support by AWS load balancers

    AWS Classic Load Balancers (formerly referred to as ELBs) support configuration of cipher suites for front end connections with clients only. When configuring Classic Load Balancers to forward requests to Gorouters over TLS, operators may encounter a Cipher Suite Mismatch error. This is because the cipher suites supported by Classic Load Balancers for TLS handshakes with back ends (Gorouters in this case) are hardcoded, undocumented, and do not support the Gorouter default cipher suites.

    You can configure TLS termination in one of the following ways:

    • Configure Classic Load Balancer listeners in TCP mode. This allows TCP connections from clients to pass through the Classic Load Balancer to Gorouters on port 443. With this configuration, Gorouters are the first point of TLS termination.

    • If you require TLS termination at an AWS load balancer in addition to terminating at the Gorouter, use AWS Application Load Balancers (ALBs) that support the Gorouter default cipher suites.

    TLS v1.3

    You cannot configure cipher suites for TLS v1.3. Gorouter only supports the defaults listed in Default Gorouter Cipher Suites.

    To support TLS v1.3, ensure that the Gorouter is configured with certificates generated with a key larger than 512 bits.

    TLS v1.2

    The following cipher suites are optionally supported for TLS v1.2 only:

    RFC OpenSSL
    TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256
    TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384
    TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ECDHE-ECDSA-RC4-SHA
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE-ECDSA-AES128-SHA
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE-ECDSA-AES256-SHA
    TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDHE-RSA-RC4-SHA
    TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE-RSA-DES-CBC3-SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE-RSA-AES128-SHA
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDHE-RSA-AES256-SHA
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384
    TLS_RSA_WITH_AES_128_CBC_SHA256 AES128-SHA256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHE-ECDSA-AES128-SHA256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 ECDHE-RSA-CHACHA20-POLY1305
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 ECDHE-ECDSA-CHACHA20-POLY1305

    TLS v1.0 and v1.1

    The following cipher suites are optionally supported for TLS v1.0 and TLS v1.1 only:

    RFC OpenSSL
    TLS_RSA_WITH_RC4_128_SHA RC4-SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
    TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
    TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

    You can override the default cipher suites in the Networking pane of the TAS for VMs tile. For more information about using custom SSL ciphers, see Gorouter Only or Load Balancer and Gorouter.

    For more information about supported ciphers, see Golang Constants in the Golang repository on GitHub and Ciphers in the OpenSSL documentation.

    Important ECDSA ciphers require a certificate and key for DSA, rather than RSA.

    Mutual authentication with clients

    The Gorouter supports validation of client certificates in TLS handshakes with clients, also known as mutual authentication. Operators can choose whether the Gorouter requests client certificates and when requesting certificates, whether or not to require them.

    By default, the Gorouter requests but does not require client certificates in TLS handshakes.

    To configure Gorouter for handling client certificates, select one of the options under Gorouter behavior for client certificate validation in the Networking pane of the TAS for VMs tile:

    • The Gorouter does not request client certificates: Client certificates are not requested, so the client does not provide them, and validation of client certificates does not occur. This option is incompatible with the TLS termination point options HAProxy and Gorouter because these options require mutual authentication.

    • The Gorouter requests but does not require client certificates: The Gorouter requests client certificates in TLS handshakes and validates them when presented, but does not require them. This is the default configuration.

    • The Gorouter requires client certificates: The Gorouter validates that the client certificate is signed by a Certificate Authority that the Gorouter trusts. If the Gorouter cannot validate the client certificate, the TLS handshake fails.

    The behavior controlled by this property is global; it applies to all requests received by Gorouters so configured.

    If the Gorouter is the first point of TLS termination (your load balancer does not terminate TLS, and passes the request through to Gorouter over TCP), consider:

    • Only the The Gorouter does not request client certificates option should be used with TAS for VMs, as the Gorouters in TAS for VMs receive requests for the system domain. Many clients of Ops Manager platform APIs do not present client certificates in TLS handshakes, so the first point of TLS termination for requests to the system domain must not request them.

    • All options may be used for Gorouters deployed with the Isolation Segment tile, as these only receive requests for app domains.

    • The The Gorouter requests but does not require client certificates and The Gorouter requires client certificates options trigger browsers to prompt users to select a certificate if the browser is not already configured with a certificate signed by one of the CAs configured for the Gorouter.

    If the Gorouter is not the first point of TLS termination, this property can be used to secure communications between the load balancer and Gorouter. The Gorouter must be configured with the CA used to sign the client certification the load balancer presents.

    After you upgrade TAS for VMs from a previous version, requests to the platform fail if your load balancer is configured with client certificates and the Gorouter is not configured with the appropriate CA. To mitigate this issue, select The Gorouter does not request client certificates or configure the Gorouter with the appropriate CA.

    Terminating TLS at the Gorouter only

    In this configuration, the load balancer does not terminate TLS for TAS for VMs domains at all. Instead, it passes through the underlying TCP connection to the Gorouter.

    VMware recommends this more performant option, establishing and terminating a single TLS connection.

    The following diagram illustrates communication between the client, load balancer, Gorouter, and app.

    Diagram of the TLS Pass-Through. The diagram shows communication between the client, load balancer, router, and the app.

    Traffic passes from the encrypted client, to the load balancer, to the router, and traffic terminates at the app. Traffic between the load balancer and the Gorouter is encrypted only if the client request is encrypted.

    Traffic between the Gorouter and app is encrypted with TLS, unless a Windows stemcell is being used.

    About HTTP header forwarding

    If you terminate TLS at the Gorouter only, your load balancer does not send HTTP headers.

    The Gorouter appends the X-Forwarded-For and X-Forwarded-Proto headers to requests forwarded to apps and platform system components.

    X-Forwarded-For is set to the IP address of the source. Depending on the behavior of your load balancer, this may be the IP address of your load balancer. For the Gorouter to deliver the IP address of the client to apps, configure your load balancer to forward the IP address of the client or configure your load balancer to send the client IP address using the PROXY protocol.

    X-Forwarded-Proto provides the scheme of the HTTP request from the client. The scheme is HTTP if the client made a request on port 80 (unencrypted) or HTTPS if the client made a request on port 443 (encrypted). The Gorouter sanitizes the X-Forwarded-Proto header based on the settings of the router.sanitize_forwarded_proto and router.force_forwarded_proto_https manifest properties as follows:

    • router.sanitize_forwarded_proto: true and router.force_forwarded_proto_https: true: The Gorouter sets the value of X-Forwarded-Proto header to HTTPS in requests forwarded to back ends.

    • router.sanitize_forwarded_proto: true and router.force_forwarded_proto_https: false: The Gorouter strips the X-Forwarded-Proto header when present in requests from front end clients. When the request is received on port 80 (unencrypted), the Gorouter sets the value of this header to HTTP in requests forwarded to back ends, When the request is received on port 443 (encrypted), the Gorouter sets the value of this header to HTTPS.

    • router.sanitize_forwarded_proto: false and router.force_forwarded_proto_https: true: The Gorouter passes through the header as received from the load balancer, without modification.

    • router.sanitize_forwarded_proto: false and router.force_forwarded_proto_https: false: The Gorouter passes through the header as received from the load balancer, without modification.

    Note: If you configured TLS to terminate at the Gorouter only, VMware recommends setting router.sanitize_forwarded_proto: true and router.force_forwarded_proto_https: false to secure against header spoofing.

    For more information about HTTP headers in TAS for VMs, see HTTP Headers in HTTP Routing. For information about configuring the forwarding of client certificates, see Forward Client Certificate to Apps in HTTP Routing.

    Procedure: Gorouter only

    To configure SSL termination on the Gorouter in TAS for VMs:

    1. Configure your load balancer to pass through TCP requests from the client to the Gorouter.

    2. Go to Ops Manager Installation Dashboard.

    3. Click the TAS for VMs tile.

    4. Select Networking.

    5. For TAS for VMs deployments on OpenStack or vSphere:

      1. Choose IP addresses for the Gorouters from the subnet configured for Ops Manager.
      2. In Gorouter IPs, enter the IP addresses you chose in the previous step.
      3. Configure your load balancer to forward requests for the preceding domains to the IP addresses you configured in the previous step. For more information, see Configure networking in Configuring TAS for VMs.

    6. In Certificates and private keys:

      1. Click Add to define at least one certificate and key pair for the Gorouter.
      2. For each certificate keypair that you add, assign a name, enter the PEM-encoded certificate chain and PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in TAS for VMs. To create a certificate for your wildcard domains, see Creating a wildcard Certificate for Ops Manager deployments in providing a certificate for your TLS termination point.

    7. For TLS versions, select the minimum version of TLS to use in Gorouter communications. The Gorouter uses TLS v1.2 by default. If you need to accommodate clients that use an older version of TLS, select a lower minimum version. For a list of TLS ciphers supported by the Gorouter, see Cipher suites.

    8. To use a specific set of TLS ciphers for the Gorouter, enter an ordered, colon-separated list of TLS cipher suites in OpenSSL format in TLS cipher suites. For example, if you have selected support for an earlier version of TLS, enter cipher suites supported by this version. For a list of TLS ciphers that the Gorouter supports, see Cipher suites. Otherwise, leave the default values in this field.

    9. In TLS termination point, select Gorouter.

    10. Under HAProxy forwards all requests to the Gorouter over TLS, select Disable.

    11. (Optional) If you do not want the Gorouter to accept any non-encrypted HTTP traffic, select the Disable HTTP on the Gorouter and HAProxy check box.

    12. Click Save.

    13. Select Resource Config.

    14. In the Instances dropdown for the HAProxy job, select 0 instances.

    15. Click Save.

    Terminating 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.

    VMware recommends this option if you cannot use SAN certificates and if you do not require traffic to be encrypted between the load balancer and the Gorouter.

    The following diagram illustrates communication between the client, load balancer, Gorouter, and app.

    alt-text=Diagram of the TLS Termination at Load Balancer.

    The diagram shows configuration of the the client, load balancer, Gorouter, and app when the TLS terminates at the load balancer with lock icons.

    Traffic starts at the encrypted client, passes through the load balancer to the router, and terminates at the app. Traffic is not encrypted past the load balancer.

    Traffic between the Gorouter and app is encrypted with TLS, unless a Windows stemcell is being used.

    About HTTP header forwarding

    If you terminate TLS at your load balancer, 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.

    For more information about HTTP headers in TAS for VMs, see HTTP Headers in HTTP Routing. If you are configuring the forwarding of client certificates, see Forward Client Certificate to Apps in HTTP Routing.

    Procedure: Load balancer only

    To configure SSL termination on the load balancer only in TAS for VMs:

    1. Create an A record in your DNS that points to your load balancer IP address. The A record associates the System domain and Apps domain that you configure in the Domains pane of the TAS for VMs tile with the IP address of your load balancer.

      For example, with pcf.example.com as the main subdomain for your Ops Manager deployment and a load balancer IP address 198.51.100.1, you must create an A record in your DNS that serves example.com and points *.pcf to 198.51.100.1.

      Name Type Data Domain
      *.pcf A 198.51.100.1 example.com

    2. Navigate to the Ops Manager Installation Dashboard.

    3. Click the TAS for VMs tile.

    4. Select Networking.

    5. For TAS for VMs deployments on OpenStack or vSphere:

      1. Choose IP addresses for the Gorouters from the subnet configured for Ops Manager.
      2. In Gorouter IPs, enter the IP addresses you chose in the previous step.
      3. Configure your load balancer to forward requests for the above domains to the IP addresses you configured in the previous step. For more information, see Configure networking in Configuring TAS for VMs.

    6. Under Certificates and private keys:

      1. Click Add to define at least one certificate and key pair for the Gorouter.
      2. For each certificate keypair that you add, assign a name, enter the PEM-encoded certificate chain and PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in TAS for VMs. To create a certificate for your wildcard domains, see Creating a wildcard certificate for Ops Manager Deployments in providing a certificate for your TLS termination point.

    7. For TLS versions, select the minimum version of TLS to use in Gorouter communications. The Gorouter uses TLS v1.2 by default. If you need to accommodate clients that use an older version of TLS, select a lower minimum version. For a list of TLS ciphers supported by the Gorouter, see Cipher suites.

    8. To use a specific set of TLS ciphers for the Gorouter, enter an ordered, colon-separated list of TLS cipher suites in OpenSSL format in TLS cipher suites. For example, if you have selected support for an earlier version of TLS, enter cipher suites supported by this version. For a list of TLS ciphers that the Gorouter supports, see Cipher suites. Otherwise, leave the default values in this field.

    9. In TLS termination point, select Infrastructure load balancer.

    10. To use a specific set of TLS ciphers for HAProxy, configure TLS cipher suites for HAProxy. Enter an ordered, colon-separated list of TLS cipher suites in the OpenSSL format. For example, if you have selected support for an earlier version of TLS, enter cipher suites supported by this version. Otherwise, leave the default values in this field.

    11. Under HAProxy forwards all requests to the Gorouter over TLS, select Disable.

    12. (Optional) If you do not want the Gorouter to accept any non-encrypted HTTP traffic, enable the Disable HTTP on the Gorouter and HAProxy check box.

    13. Click Save.

    14. After you complete the configuration in TAS for VMs, add your certificate or certificates to your load balancer and configure its listening port. The procedures vary depending on your IaaS.

    15. Configure your load balancer to append the X-Forwarded-For and X-Forwarded-Proto headers to client requests.
      If you cannot configure the load balancer to provide the X-Forwarded-For header, the Gorouter appends it in requests forwarded to apps and system components, set to the IP address of the load balancer.

      Important If the load balancer accepts unencrypted requests, it must provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it must not accept unencrypted requests. Otherwise, apps and platform system components that require encrypted client requests accept unencrypted requests when they must not accept them.

    Terminating TLS at the load balancer and 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.

    Diagram of the TLS Termination at Load Balancer and Router. The diagram shows configuration of the client, load balancer, Gorouter, and app when the TLS terminates at the load balancer and the router with lock icons. See long description below.

    Traffic starts at the encrypted client, moves through the load balancer to the router, and terminates at the unencrypted app. Traffic is encrypted between the client and load balancer, and between the load balancer and router.

    This option is less performant, but allows for termination at a load balancer, as well as secure traffic between the load balancer and the Gorouter.

    Traffic between the Gorouter and app is encrypted with TLS, unless a Windows stemcell is being used.

    Certificate guidelines

    In this deployment scenario, the following guidelines apply:

    • Certificates for the TAS for VMs domains must be stored on the load balancer, as well as on the Gorouter.

    • Generate certificates for your load balancer and the Gorouter with different keys. If the key for the certificate on the Gorouter is compromised, then the certificate on the load balancer is not at risk, and vice-versa.

    • If you choose to host only one certificate on the Gorouter and many on your load balancer, configure your load balancer with the CA and host name with which to validate the certificate hosted by the Gorouter.

    About host name verification

    Host name verification between the load balancer and the Gorouter is unnecessary when the load balancer is already configured with the Gorouter’s IP address to correctly route the request.

    If the load balancer uses DNS resolution to route requests to the Gorouters, then you should enable host name verification.

    About HTTP header forwarding

    If you terminate TLS at your load balancer, you must configure the load balancer to append the X-Forwarded-For and X-Forwarded-Proto HTTP headers to requests it sends to the Gorouter.

    If you terminate TLS at your load balancer but it does not support HTTP, such that it cannot append HTTP headers, a workaround exists. You should use this workaround only if your load balancer does not accept unencrypted requests. Configure your load balancer to send the client IP address using the PROXY protocol, and enable PROXY in the Gorouter. As the X-Forwarded-Proto header is stripped, configure the Gorouter to force-set this header to ‘HTTPS’.

    For more information about HTTP headers in TAS for VMs, see HTTP Headers in HTTP Routing. If you are configuring the forwarding of client certificates, see Forward Client Certificate to Apps in HTTP Routing.

    Procedure: Load balancer and Gorouter

    To configure SSL termination on the Gorouter and load balancer in TAS for VMs:

    1. Create an A record in your DNS that points to your load balancer IP address. The A record associates the System domain and Apps domain that you configure in the Domains pane of the TAS for VMs tile with the IP address of your load balancer.

      For example, with pcf.example.com as the main subdomain for your Ops Manager deployment and a load balancer IP address 198.51.100.1, you must create an A record in your DNS that serves example.com and points *.pcf to 198.51.100.1.

      Name Type Data Domain
      *.pcf A 198.51.100.1 example.com

    2. Go to Ops Manager Installation Dashboard.

    3. Click the TAS for VMs tile.

    4. Select Networking.

    5. For TAS for VMs deployments on OpenStack or vSphere:

      1. Choose IP addresses for the Gorouters from the subnet configured for Ops Manager.
      2. In Gorouter IPs, enter the IP addresses you chose in the previous step.
      3. Configure your load balancer to forward requests for the above domains to the IP addresses you configured in the previous step. For more information, see Configure Networking in Configuring TAS for VMs.

    6. Under Certificates and private keys:

      1. Click Add to define at least one certificate and key pair for the Gorouter.
      2. For each certificate keypair that you add, assign a name, enter the PEM-encoded certificate chain and PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in TAS for VMs. To create a certificate for your wildcard domains, see Creating a wildcard certificate for Ops Manager deployments in providing a certificate for your TLS termination point.

    7. In the Minimum version of TLS supported by the Gorouter and HAProxy, select the minimum version of TLS to use in HAProxy and Gorouter communications. The Gorouter uses TLS v1.2 by default. If you need to accommodate clients that use an older version of TLS, select a lower minimum version. For a list of TLS ciphers supported by the Gorouter, see Cipher Suites.

    8. If you are using HAProxy:

      1. Under TLS termination point, select Infrastructure load balancer.
      2. Under HAProxy forwards all requests to the Gorouter over TLS, select Enable.
      3. In the Certificate authority for HAProxy back end field, specify the certificate authority (CA) that signed the certificate you configured in the Certificates and private keys for the Gorouter and HAProxy field.

        Note: If you used the Generate RSA Certificate link to generate a self-signed certificate, then the CA to specify is the Ops Manager CA, which you can locate using the `/api/v0/certificate_authorities` endpoint in the Ops Manager API.

      4. If you want to use a specific set of TLS ciphers for HAProxy, configure TLS cipher suites for HAProxy. Enter an ordered, colon-separated list of TLS cipher suites in the OpenSSL format. For example, if you have selected support for an earlier version of TLS, you can enter cipher suites supported by this version. Otherwise, leave the default values in this field.
      5. Proceed to step 11.

    9. To use a specific set of TLS ciphers for the Gorouter, configure TLS cipher suites for the Gorouter. Enter an ordered, colon-separated list of TLS cipher suites in the OpenSSL format. For example, if you have selected support for an earlier version of TLS, enter cipher suites supported by this version. For a list of TLS ciphers supported by the Gorouter, see Cipher Suites. Otherwise, leave the default values in this field.

    10. If you are not using HAProxy:

      1. Under TLS termination point, select any of the available options depending on your client app needs. For more information about XFCC header forwarding, see Forward Client Certificate to Apps in HTTP Routing.
      2. Under HAProxy forwards all requests to the Gorouter over TLS, select Disable.
      3. In the TAS for VMs tile, select Resource Config.
      4. In the Instances dropdown for the HAProxy job, select 0 instances.
      5. Click Save.

    11. (Optional) If you do not want the Gorouter to accept any non-encrypted HTTP traffic, select the Disable HTTP on the Gorouter and HAProxy check box.

    12. Click Save.

    13. Configure your load balancer to append the X-Forwarded-For and X-Forwarded-Proto headers to client requests.
      If you cannot configure the load balancer to provide the X-Forwarded-For header, the Gorouter appends it in requests forwarded to apps and system components, set to the IP address of the load balancer.

      If the load balancer accepts unencrypted requests, it must provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it must not accept unencrypted requests. Otherwise, apps and platform system components that require encrypted client requests accept unencrypted requests when they must not accept them.

check-circle-line exclamation-circle-line close-line
Scroll to top icon