Securing Traffic into Cloud Foundry

Page last updated:

This topic describes the options for securing HTTP traffic into your Elastic Runtime deployment with SSL/TLS certificates. You can configure the location where your deployment terminates TLS depending on your needs and certificate restrictions.

Protocol Support

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

To secure non-HTTP traffic over TCP Routing, terminate TLS at your load balancer or at the application. See TCP Routing for details.

SSL/TLS Termination Options for HTTP Routing

There are several 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.

If the following applies to you: Then configure SSL/TLS termination at: Related topic and configuration procedure
  • You want the optimum balance of performance and security, and
  • You can use a single certificate with SANs in your deployment for your wildcard domains, and
  • You want to make minimum changes to your load balancer, or
  • You are deploying CF to AWS. For information on AWS limitations, see TLS Cipher Suite Support by AWS ELBs.
Gorouter only Terminating SSL/TLS at the Gorouter Only
  • You require TLS termination at a load balancer, or
  • You want the highest level of security, and
  • You can use a single SAN certificate on the Gorouter, and
  • You do not mind a slightly less performant deployment.
Load Balancer and Gorouter Terminating SSL/TLS at the Load Balancer and Gorouter
  • You require TLS termination at a load balancer, and
  • You cannot use a single SAN certificate for all system and application domains for your deployment, or
  • You prefer unencrypted traffic between Load Balancer and Gorouter.
Load Balancer only Terminating SSL/TLS at the Load Balancer Only
Optionally, if you are deploying HAProxy, andThen in addition, terminate SSL/TLS at:Related topic and configuration procedure
  • You would like to secure traffic to the HAProxy, and
  • You can use a single SAN certificate for your deployment for your wildcard domains.
HAProxyTerminating SSL/TLS at HAProxy

Certificate Requirements

The following requirements apply to the certificates you use to secure traffic into Elastic Runtime:

  • You must obtain at least one SSL/TLS certificate for your environment.
    • 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. You can generate a self-signed certificate with openssl or a similar tool.

      Alternately, you can use the Elastic Runtime Ops Manager interface to generate a certificate for you. Certificates generated in Elastic Runtime 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.

  • Certificates used in CF must be encoded in the PEM format.
  • Gorouter only supports a single TLS certificate key-pair. In addition, if you are using HAProxy, Gorouter and HAProxy are configured with the same TLS certificate.
  • The Gorouter supports mutual TLS, and validates a client provided certificate chain against its CA certificates if one is provided in the TLS handshake, but does not require it. Depending on whether you choose to terminate at both the Load Balancer and Gorouter, or at Gorouter alone, the client certificate may be that of the load balancer or of the originating client.
  • The certificate on the Gorouter must be associated with the correct hostname so that HTTPS can validate the request.
  • If wildcard certificates are not supported for some or all of your domains, then configure termination requests at the load balancer only. In this type of deployment, the load balancer passes unencrypted traffic to the Gorouter. As a result, you avoid having to reissue and reinstall certificates on the Gorouter for every app or UAA security zone.
  • Extended Validation (EV) certificates support multiple hostnames, like SAN, but do not support wildcards. As Gorouter has not been tested with EV certificates, if EV certificates are required, then terminate TLS/SSL at the load balancer only.

TLS Cipher Suite Support

Some CF components like 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 Gorouter supports the following TLS cipher suites, both of which require TLS v1.2:

RFC OpenSSL
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384

You can override the default cipher suites in the TLS Cipher Suites for Router field in the Networking tab of the Elastic Runtime tile. See the following procedures for either Gorouter Only or Load Balancer and Gorouter for more information about using custom SSL ciphers.

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 backends (Gorouters in this case) are hardcoded, undocumented, and do not support the Gorouter default cipher suites.

Operators have three options:

  • Configure Classic Load Balancer listeners in TCP mode so that TCP connections from clients are passed through the Classic Load Balancer to Gorouters on port 443. Then Gorouters are the first point of TLS termination. This option is the recommended solution.
  • If you require TLS termination at an AWS load balancer in addition to terminating at Gorouter, use AWS Application Load Balancers (ALBs) that support the Gorouter default cipher suites.
  • Configure Gorouter to support an older TLS version (v1.1 or v1.0) and then configure any of the TLS v1.0 or v1.1 cipher suites listed below in addition to the defaults. This option is the least secure option and should be used only if you are required to use an AWS Classic Load Balancer and also require TLS termination at both the load balancer and the Gorouter.

    To add an older cipher suite to the Gorouter cipher suites, perform the following steps:

    1. In the Networking configuration screen of Elastic Runtime, select either TLS v1.0 or v1.1 in the Minimum version of TLS supported by HAProxy and Router field.
    2. Add one or more of the Gorouter-supported cipher suites listed in TLS v1.0 and v1.1 to the existing list of default cipher suites in the TLS Cipher Suites for Router field.
    For more information, see the Elastic Runtime configuration documentation for your IaaS. For example, if you are deploying PCF on GCP, then see Deploying Elastic Runtime on GCP.


    Since this option relies on using an older cipher suite, consult your security team before implementing this solution.

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 TLS Cipher Suites for Router field in the Networking tab of the Elastic Runtime tile. See the following procedures for either Gorouter Only or Load Balancer and Gorouter for more information about using custom SSL ciphers.

See Golang Constants and OpenSSL Cipher Suites for more information about supported ciphers.

Note: ECDSA ciphers require a certificate and key for DSA, as opposed to RSA.

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.

Pass through

Traffic between the load balancer and the Gorouter is encrypted only if the client request is encrypted.

Certificate Guidelines

  • The Gorouter currently supports configuring multiple HTTPS certificates using the router.tls_pem property.
  • Use of Subject Alternative Names is recommended because Elastic Runtime requires wildcard domains.

About HTTP Header Forwarding

If you terminate TLS/SSL 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 applications 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 Gorouter to deliver the IP address of the client to applications, 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. Gorouter will set X-Forwarded-Proto to the scheme of the client request.

For more information on HTTP headers in CF, see HTTP Headers. If you are configuring the forwarding of client certificates, see Forward Client Certificate to Applications.

Procedure: Gorouter Only

Perform the following steps to configure SSL termination on the Gorouter in Pivotal Cloud Foundry (PCF):

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

  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. For PCF deployments on OpenStack or vSphere, choose IP addresses for the Gorouters from the subnet configured for Ops Manager and enter them in the Router IPs field. Then configure your load balancer to forward requests for the above domains to these IP addresses. For more information, see the Elastic Runtime networking configuration topic for OpenStack or vSphere.

  6. In the Certificate and Private Key for HAProxy and Router fields, enter your PEM-encoded certificate and your PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in Elastic Runtime. For options and instructions on creating a certificate for your wildcard domains, see Creating a Wildcard Certificate for PCF Deployments.

  7. In the Minimum version of TLS supported by HAProxy and Router, select the minimum version of TLS to use in Gorouter communications. Gorouter use 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. Under HAProxy forwards requests to Router over TLS, select Disable.

  9. If you want to use a specific set of TLS ciphers for the Router, configure TLS Cipher Suites for Router. 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. For a list of TLS ciphers supported by the Gorouter, see Cipher Suites. Otherwise, leave the default values in this field.

  10. (Optional) If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

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

  12. In the Configure the CF Router support for the X-Forwarded-Client-Cert header field, select the third option, Strip the XFCC header when present and set it to the client certificate.

  13. Click Save.

  14. In the Elastic Runtime tile, click Resource Config.

  15. In the Instances drop down for the HAPRoxy job, select 0 instances.

  16. Click Save.

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

Lb

Certificate Guidelines

You can use multiple certificates on your load balancer if the load balancer supports multiple VIPs or SNI.

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.

For more information on HTTP headers in CF, see HTTP Headers. If you are configuring the forwarding of client certificates, see Forward Client Certificate to Applications.

Procedure: Load Balancer Only

Perform the following steps to configure SSL termination on the load balancer only in Pivotal Cloud Foundry (PCF):

  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 section of the Elastic Runtime tile with the IP address of your load balancer.

    For example, with cf.example.com as the main subdomain for your Cloud Foundry 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 *.cf to 198.51.100.1.

    Name Type Data Domain
    *.cf A 198.51.100.1 example.com
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. For PCF deployments on OpenStack or vSphere, choose IP addresses for the Gorouters from the subnet configured for Ops Manager and enter them in the Router IPs field. Then configure your load balancer to forward requests for the above domains to these IP addresses. For more information, see the Elastic Runtime networking configuration topic for OpenStack or vSphere.

  6. In the Certificate and Private Key for HAProxy and Router fields, enter your PEM-encoded certificate and your PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in Elastic Runtime. For options and instructions on creating a certificate for your wildcard domains, see Creating a Wildcard Certificate for PCF Deployments.

  7. In the Minimum version of TLS supported by HAProxy and Router, select the minimum version of TLS to use in HAProxy communications. HAProxy use 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 HAProxy, see Cipher Suites.

  8. Under HAProxy forwards requests to Router over TLS, select Disable.

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

  10. (Optional) If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

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

  12. In the Configure the CF Router support for the X-Forwarded-Client-Cert header field, select Always forward the XFCC header in the request, regardless of the whether the client connection is mTLS.

  13. Click Save.

  14. After you complete the configuration in PCF, 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 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.

    Note: 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 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.

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

Lb 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 Gorouter.

Certificate Guidelines

In this deployment scenario, the following guidelines apply:

  • Certificates for the Elastic Runtime domains must be stored on the load balancer, as well as on Gorouter.
  • Generate certificates for your load balancer and 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.
  • Configure your load balancer with the CA and hostname with which to validate the certificate hosted by the Gorouter.

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 the load balancer uses DNS resolution to route requests to the Gorouters, then you should enable hostname verification.

About HTTP Header Forwarding

If you terminate SSL/TLS at your load balancer, then 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 SSL/TLS at your load balancer but it does not support HTTP, such that it cannot append HTTP headers, a workaround exists. We recommend you 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 Gorouter. As the X-Forwarded-Proto header will not be present, configure Gorouter to force-set this header to ‘HTTPS’.

For more information on HTTP headers in CF, see HTTP Headers. If you are configuring the forwarding of client certificates, see Forward Client Certificate to Applications.

Procedure: Load Balancer and Gorouter

Perform the following steps to configure SSL termination on the Gorouter and load balancer in Pivotal Cloud Foundry (PCF):

  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 section of the Elastic Runtime tile with the IP address of your load balancer.

    For example, with cf.example.com as the main subdomain for your Cloud Foundry (CF) 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 *.cf to 198.51.100.1.

    Name Type Data Domain
    *.cf A 198.51.100.1 example.com
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. For PCF deployments on OpenStack or vSphere, choose IP addresses for the Gorouters from the subnet configured for Ops Manager and enter them in the Router IPs field. Then configure your load balancer to forward requests for the above domains to these IP addresses. For more information, see the Elastic Runtime networking configuration topic for OpenStack or vSphere.

  6. In the Certificate and Private Key for HAProxy and Router fields, enter your PEM-encoded certificate and your PEM-encoded private key. You can either upload your own certificate or generate an RSA certificate in Elastic Runtime. For options and instructions on creating a certificate for your wildcard domains, see Creating a Wildcard Certificate for PCF Deployments.

  7. In the Minimum version of TLS supported by HAProxy and Router, select the minimum version of TLS to use in HAProxy and Gorouter communications. Gorouter use 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, complete the following steps:

    1. Under HAProxy forwards requests to Router over TLS, select Enable.
    2. In the Certificate Authority for HAProxy Backend field, specify the Certificate Authority (CA) that signed the certificate you configured in the Certificate and Private Key for HAProxy and Router field.

      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 at the /api/v0/certificate_authorities endpoint in the Ops Manager API.

    3. 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.
    4. In the Configure the CF Router support for the X-Forwarded-Client-Cert header field, select Always forward the XFCC header in the request, regardless of the whether the client connection is mTLS.
    5. Proceed to step 11.
  9. If you want to use a specific set of TLS ciphers for the Router, configure TLS Cipher Suites for Router. 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. 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, complete the following steps:

    1. Under HAProxy forwards requests to Router over TLS, select Disable.
    2. In the Configure the CF Router support for the X-Forwarded-Client-Cert header field, select any of the available options depending on your client application needs. For more information about XFCC header forwarding, see Forward Client Certificate to Applications.
    3. In the Elastic Runtime tile, click Resource Config.
    4. In the Instances drop down for the HAPRoxy job, select 0 instances.
    5. Click Save.
  11. (Optional) If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

  12. (Optional) If you do not want HAProxy or the Gorouter to accept any non-encrypted HTTP traffic, select the Disable HTTP on HAProxy and Router checkbox.

  13. Click Save.

  14. After you complete the configuration in PCF, 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 applications and system components, set to the IP address of the load balancer.

    Note: 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 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.

Support for SNI

Gorouter’s router.tls_pem property enables support for SNI which allows operators to configure Gorouter with multiple certificates. This property replaces router.ssl_key and router.ssl_cert which were previously required to terminate SSL/TLS.

The router.tls_pem property supports both RSA and ECDSA certificates in PEM encoding. This property is an array where each entry is a combination of private key and certificate. In the case that a certificate chain is required, the order should be as follows: primary certificate, intermediate certificate, then root certificate. The private key can be either appended or prepended.

 properties:
    router:
      tls_pem:
      - |
         -----BEGIN ENCRYPTED PRIVATE KEY-----
         MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDg
         MBQGCCqGSIb3DQMHBAgD1kGN4ZslJgSCBMi1xk9jhlPxPc
         9g73NQbtqZwI+9X5OhpSg/2ALxlCCjbqvzgSu8gfFZ4yo+
         A .... MANY LINES LIKE THAT ....
         X0R+meOaudPTBxoSgCCM51poFgaqt4l6VlTN4FRpj+c/Wc
         blK948UAda/bWVmZjXfY4Tztah0CuqlAldOQBzu8TwE7WD
         H0ga/iLNvWYexG7FHLRiq5hTj0g9mUPEbeTXuPtOkTEb/0
         GEs=
         -----END ENCRYPTED PRIVATE KEY-----
         -----BEGIN CERTIFICATE-----
         MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3Df
         BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVx
         aWRnaXRzIFB0eSBMdGQwHhcNMTExMjMxMDg1OTQ0WhcNMT
         A .... MANY LINES LIKE THAT ....
         JjyzfN746vaInA1KxYEeI1Rx5KXY8zIdj6a7hhphpj2E04
         C3Fayua4DRHyZOLmlvQ6tIChY0ClXXuefbmVSDeUHwc8Yu
         B7xxt8BVc69rLeHV15A0qyx77CLSj3tCx2IUXVqRs5mlSb
         vA==
         -----END CERTIFICATE-----
      - |
         -----BEGIN ENCRYPTED PRIVATE KEY-----
         MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDg
         MBQGCCqGSIb3DQMHBAgD1kGN4ZslJgSCBMi1xk9jhlPxPc
         9g73NQbtqZwI+9X5OhpSg/2ALxlCCjbqvzgSu8gfFZ4yo+
         A .... MANY LINES LIKE THAT ....
         X0R+meOaudPTBxoSgCCM51poFgaqt4l6VlTN4FRpj+c/Wc
         blK948UAda/bWVmZjXfY4Tztah0CuqlAldOQBzu8TwE7WD
         H0ga/iLNvWYexG7FHLRiq5hTj0g9mUPEbeTXuPtOkTEb/0
         GEs=
         -----END ENCRYPTED PRIVATE KEY-----
         -----BEGIN CERTIFICATE-----
         MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3Df
         BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVx
         aWRnaXRzIFB0eSBMdGQwHhcNMTExMjMxMDg1OTQ0WhcNMT
         A .... MANY LINES LIKE THAT ....
         JjyzfN746vaInA1KxYEeI1Rx5KXY8zIdj6a7hhphpj2E04
         C3Fayua4DRHyZOLmlvQ6tIChY0ClXXuefbmVSDeUHwc8Yu
         B7xxt8BVc69rLeHV15A0qyx77CLSj3tCx2IUXVqRs5mlSb
         vA==
         -----END CERTIFICATE-----
        -----BEGIN CERTIFICATE-----
         MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3Df
         BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVx
         aWRnaXRzIFB0eSBMdGQwHhcNMTExMjMxMDg1OTQ0WhcNMT
         A .... MANY LINES LIKE THAT ....
         JjyzfN746vaInA1KxYEeI1Rx5KXY8zIdj6a7hhphpj2E04
         C3Fayua4DRHyZOLmlvQ6tIChY0ClXXuefbmVSDeUHwc8Yu
         B7xxt8BVc69rLeHV15A0qyx77CLSj3tCx2IUXVqRs5mlSb
         vA==
         -----END CERTIFICATE-----

The first certificate listed acts as the default certificate. This has the equivalent behavior as the previous property router.ssl_cert and router.ssl_key.

When TLS is enabled in Gorouter, the behavior is as follows:

  • If a client provides an SNI header with a ServerName that matches to a certificate in router.tls_pem, Gorouter will return the matching certificate
  • If a client provides an SNI header with a ServerName that does not match to a certificate in router.tls_pem, Gorouter will return the default certificate
  • If a client does not provide an SNI header and the requested hostname matches to a certificate in router.tls_pem, Gorouter will return the matching certificate.
  • If a client does not provide an SNI header and requested hostname does not match to a certificate in router.tls_pem, Gorouter will return the default certificate.
Create a pull request or raise an issue on the source for this page in GitHub