Okta Access Gateway Fails to Connect to Protected Resource Due to SNI Extension Requirement

Okta Access Gateway (OAG) fails to connect to a protected resource when the network environment requires a Transport Layer Security (TLS) Server Name Indication (SNI) extension. Configuring an advanced policy in OAG to include the SNI extension or modifying the network rules resolves the issue. When this connection failure occurs, users experience a login loop or encounter an error message.

Application is not responding

OAG receives a connection reset after sending the TLS "Client Hello" to the protected resource.

OAG logs the following connection reset error.

Additionally, a curl test from OAG to the protected resource IP address fails after the TLS "Client Hello", but a curl test from OAG to the protected resource hostname succeeds.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Access Gateway (OAG)

By default, OAG connects to a protected resource via its IP address and does not include the SNI extension in the TLS "Client Hello". Network environments with security policies that require clients to include the target hostname in the TLS handshake will reject the connection.

How is the SNI extension requirement resolved?

Administrators can resolve this issue by configuring an advanced policy in OAG or by modifying the network rules.

Configure an advanced policy in OAG to send the SNI extension in the TLS "Client Hello". Replace <protectedresourcehostname.domain> with the appropriate value for the network environment.

proxy_ssl_name <protectedresourcehostname.domain>;
proxy_ssl_server_name on;

Alternatively, consult with the network team to reconfigure the network rules so that the SNI extension is not required for connections from OAG to the protected resource.