Enable non-SNI clients

This topic explains how to enable non-SNI clients for use with Apigee hybrid.

How to configure a non-SNI client

This section explains how to enable support for non-SNI (Server Name Indication) clients in Apigee hybrid.

SNI defines how a TLS peer (client) will specify the hostname it intends to connect to during the initial TLS handshake. SNI has been part of TLS since 2003. Prior to SNI, when a TLS peer sent a HELLO to begin the handshake, the receiving peer always responded with the same credentials. SNI was introduced to allow a single load-balancer to support multiple distinct hostnames and credential sets for TLS connection management. SNI is now used by the vast majority of TLS clients.

There are exceptions. As one example, the Google Cloud Load Balancer will use a non-SNI handshake to connect to backends.

If you want to configure your Apigee hybrid to be able to handle TLS handshakes that do not use SNI, either because your Apigee hybrid is a backend to a Google Cloud Load Balancer, or because your Apigee hybrid must support some other non-SNI client, then you should follow the steps described below. Non-SNI negotiation will act as a fallback; Apigee hybrid will use it for any client that does not use SNI.

  1. Create an ApigeeRoute resource. Be sure that enableNonSniClient is set to true: 
    apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: ROUTE_NAME
  namespace: APIGEE_NAMESPACE
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: CREDENTIAL_NAME
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  selector:
    app: apigee-ingressgateway
  enableNonSniClient: true

    Where:

    • ROUTE_NAME is the name you give to the custom resource (CR).
    • CREDENTIAL_NAME is the name of a Kubernetes Secret deployed to the cluster that contains TLS credentials for your virtualhost. You can find the credential name with the following kubectl Command: 
      kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName
    • hostnames must be set to the wildcard "*".
  2. Open your overrides file and make the change described in the next step.
  3. For each environment group, add the ApigeeRoute name to the additionalGateways property. For example: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["ROUTE_NAME"]
  4. Save the CRD file. For example: ApigeeRoute.yaml
  5. Apply the CRD to the cluster: 
    kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE
  6. Apply the change to virtualhosts. If you have set the $ENV_GROUP environment variable in your shell, you can use that in the following commands: 
    helm upgrade $ENV_GROUP apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=$ENV_GROUP \
  -f OVERRIDES_FILE.yaml

Usage notes

  • What happens if the cluster has more than one org?

    Since the ingress is at the cluster level for a given port (443), and there can only be one key/cert pair for the ApigeeRoute CRD, all orgs must share the same key/cert pair.

  • What happens if the cluster has more than one environment group? Will it work if the virtual hosts share the same key/cert pair?

    All hostnames across all environment groups must use the same key/cert pair.

  • Why are we creating an ApigeeRoute instead of Gateway?

    ApigeeRoutes can be validated by Apigee; however, Gateway (the Istio CRD) cannot be. Technically, even Gateway can work, but we can prevent potential configuration mistakes (through a validation webhook).

  • How can I configure non-SNI clients for Apigee?

    If your Apigee instance is exposed through a Google Load Balancer, then the Load Balancer supports non-SNI clients as explained in the Load Balancing documentation. Otherwise, if you have exposed an Apigee instance through an internal PSC endpoint or VPC, by default the Apigee instance supports non-SNI clients.