Rolling out TLS 1.3 with an Nginx reverse proxy

During a security audit at the Korea Press Foundation (KPF), the GAIS (Government Advertising Integrated Support System) platform was flagged for still serving TLS 1.0/1.1. The seemingly easiest path was to bump the TLS version at the cloud WAF, but doing so could break the API traffic between the platform and internal ERP systems, so I could not raise it right away. The other lever was WebtoB's shared SSL configuration, which was even trickier — several JEUS containers shared the same SSL settings, so a global change would ripple across every connected development server. It was the classic "fix one thing, break everything else" setup.

• Audit flagged TLS 1.0/1.1

  Production services had to be raised to TLS 1.2 or above

• Changing the WAF needed ERP API compatibility checks first

  API traffic with internal systems had to be validated before flipping the switch

• WebtoB shared SSL had a wide blast radius

  Multiple JEUS containers shared the same SSL settings — a global change risked a full outage

Instead of touching the global configuration, I placed Nginx in front as a reverse proxy and used it as the SSL termination point. The client ↔ Nginx leg runs TLS 1.2/1.3, while the Nginx ↔ WebtoB leg runs over internal HTTP (port 8099). This satisfies the security requirement while leaving the existing WebtoB/JEUS stack untouched.

Because WebtoB shares a single SSL configuration across multiple JEUS containers, any global TLS change that breaks internal API traffic impacts every connected development server at once. Putting Nginx in front isolates that risk and also makes it easy to manage TLS policies per domain.

1. 01

   Install Nginx and configure SSL/TLS

   I installed Nginx on the target server and defined the certificate paths, TLS versions, and proxy forwarding headers in ssl_proxy.conf. I left only TLSv1.2 and TLSv1.3 under ssl_protocols, so the weaker earlier versions are rejected outright.

   ssl_proxy.conf

   nginx

   # /etc/nginx/conf.d/ssl_proxy.conf
   server {
       listen       443 ssl;
       server_name  devtest.goad.or.kr;
    
       ssl_certificate      /etc/nginx/ssl/fullchain.pem;
       ssl_certificate_key  /etc/nginx/ssl/private.key;
       ssl_protocols        TLSv1.2 TLSv1.3;
    
       location / {
           proxy_pass         http://127.0.0.1:8099;
           proxy_set_header   Host               $host;
           proxy_set_header   X-Real-IP          $remote_addr;
           proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;
           proxy_set_header   X-Forwarded-Proto  $scheme;
       }
   }

2. 02

   Switch the WebtoB http.m listener port

   The WebtoB virtual server that used to listen on 443 directly was switched to the internal port (8099) that Nginx forwards to. Nginx handles TLS termination while WebtoB's shared SSL configuration stays in place — a clean separation of responsibilities.

   http.m

   config

   # WebtoB http.m — switch from 443 to the internal port
   v_issga_dev_test_ssl
       DOCROOT       = "/kpf_data/docroot/issga_dev_test",
       HOSTNAME      = "devtest.goad.or.kr",
       HOSTALIAS     = "10.30.10.12,175.45.222.244",
       # PORT        = "443",     # previous: external 443 listener
       PORT          = "8099",    # new: internal port that Nginx forwards to
       SSLFLAG       = Y,
       SSLNAME       = "ssl_issga",
       ServiceOrder  = "ext,uri",
       ERRORDOCUMENT = "400,401,403,404,405,406,503",
       METHOD        = "GET, POST, HEAD, -OPTIONS",
       LOGGING       = "acc_issga_dev_test",
       ERRORLOG      = "err_issga_dev_test",
       NodeName      = "tmax"

3. 03

   Roll out per domain, then validate the ERP APIs

   I raised the TLS version on a test domain first, verified that the main internal ERP APIs (query, create, update) still worked end-to-end, and once everything checked out, completed the TLS 1.3 rollout on the production servers.

• TLS 1.3 rolled out without affecting existing services

  By moving TLS termination up to the Nginx layer instead of touching WebtoB's shared SSL configuration, the audit requirement (TLS 1.2 or higher) was satisfied with no impact on existing services.

• TLS policies now managed independently per domain

  When a specific domain needs a different cipher suite or certificate — or needs to be tested in isolation — I can now do that without touching any of the other services.