Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
We encountered an issue while setting up HTTPS traffic from an AWS Application Load Balancer (ALB) to our NGINX Ingress Controller deployed in a private EKS cluster. Specifically:
HTTPS โ HTTP
(ALB terminates SSL, sends plain HTTP to NGINX): WorkedHTTPS โ HTTPS
(ALB forwards SSL directly to NGINX): Did not work443
SSL handshake
or bad certificate
errorsThis worked because the NGINX Ingress was listening on HTTP internally, and the ALB decrypted HTTPS before forwarding it.
This failed because NGINX Ingress was not configured to present a certificate by default when the ALB initiated a TLS handshake.
To solve this, we added the following flag to the NGINX Ingress Controller deployment:
--default-server-tls-secret=aptia-ov3-dev/ov3-fe-dev-tls
By default, NGINX Ingress only presents a certificate if a matching TLS Ingress resource is hit. However, during:
/
),NGINX has no cert to present unless a default is defined.
Make sure you have a Kubernetes TLS secret created like:
apiVersion: v1
kind: Secret
metadata:
name: ov3-fe-dev-tls
namespace: aptia-ov3-dev
type: kubernetes.io/tls
data:
tls.crt: <base64_cert>
tls.key: <base64_key>
In your Helm values or manifest:
controller:
extraArgs:
default-server-tls-secret: "aptia-ov3-dev/ov3-fe-dev-tls"
Or, if you’re using raw manifests:
args:
- --default-server-tls-secret=aptia-ov3-dev/ov3-fe-dev-tls
After setting the --default-server-tls-secret
:
Lesson | Explanation |
---|---|
ALB cannot connect via HTTPS unless NGINX has a default cert | Because TLS handshake fails without a cert |
NGINX must serve a certificate even when no Ingress is matched | Required for root path/health checks |
Always define --default-server-tls-secret when using HTTPS passthrough | Especially with ALBs on private EKS clusters |