Old Certificate Still Presented for an Okta Access Gateway Application
Last Updated:
Overview
After uploading a new certificate to Okta Access Gateway (OAG) and associating it with a specific application, the client browser still displays the old certificate. This issue occurs due to NGINX reload failures, High Availability (HA) synchronization issues, or Transport Layer Security (TLS) termination at the front-end load balancer. Resolve this by verifying the certificate format, checking NGINX and HA statuses, or updating the certificate directly on the load balancer.
Applies To
- Okta Access Gateway (OAG)
- Okta Classic Engine
- Okta Identity Engine (OIE)
Cause
The new certificate might have an issue preventing NGINX from properly reloading. Alternatively, an HA issue prevents the admin node from pushing the new certificate to the worker nodes. Finally, the network topology might implement TLS termination at the front-end load balancer, meaning OAG does not present the certificate to the client.
The following diagram illustrates the network topology involving TLS termination at the front-end load balancer:
Solution
What steps resolve the old certificate issue in Okta Access Gateway?
Verify the certificate format, check the service statuses, and bypass the load balancer to confirm the certificate presentation by following these steps:
- Upload the certificate only on the Admin node. Administrators do not need to upload the certificate on the Worker nodes.
- If all applications use a common certificate, configure the update by selecting Update Certificate in the Admin Console > Settings > Certificates to associate the default host certificate.
- If the certificate is specific to an individual application, go to the OAG Admin Console, select the application, go to Settings from Edit App, and select the new certificate in the Certificates section.
- If the new certificate fails to upload via the Management Console, verify that it is in Privacy Enhanced Mail (PEM) format and does not require a password by reviewing the OAG reports PEM do_header bad password read error message while uploading a certificate article.
- If OAG successfully uploads the certificate, verify the service statuses and monitor the logs by performing the following checks:
- Check the status of the NGINX service to determine if it properly reloaded after associating the new certificate.
- Check the HA status to ensure that the admin node successfully pushes the new certificate to the worker nodes.
- Monitor the OAG logs for any further clues.
- If OAG successfully uploads and associates the certificate without errors, and the NGINX service and HA statuses are healthy, the network topology likely implements TLS termination at the front-end load balancer. In this configuration, the load balancer presents the certificate to the client. Update the certificate on the load balancer side.
- Verify the load balancer configuration by using the workstation host file to create an entry that points the application URL directly to OAG. Refer to the Spoofing documentation for instructions. Bypassing the load balancer reveals the certificate presented by OAG. If the updated certificate appears, OAG successfully updated the certificate, but the load balancer still presents the old certificate.
Additional Resources for TLS Termination and Certificate Management
Review the following resources for more details on TLS termination and its role in certificate management:
