Web Server Load Balancing with NGINX Plus

This week, the OpenSSL team announced a new “high‑severity” vulnerability and published full details shortly after. This vulnerability (designated CVE‑2015‑1793) could allow a malicious user to exploit the certificate verification process in OpenSSL, allowing him to impersonate another user or website. For more information, check out this concise analysis and this detailed video overview.

How Does This Vulnerability Affect NGINX?

When you configure client certificate verification or validation of upstream server certificates in NGINX, it uses the certificate verification process in OpenSSL. During the process, a client or server certificate is matched against a set of trusted root certificates you provide. If the process is subverted, a certificate might pass the test even if it’s not signed by a trusted root certificate. The implication is that an attacker might potentially impersonate another user or an upstream server.

Does This Vulnerability Affect Me?

If you have configured certificate verification in NGINX and are using a vulnerable version of OpenSSL, you need to upgrade your OpenSSL installation.

To check the version of OpenSSL used by NGINX, run the nginx ‑V command:

$ nginx -V
nginx version: nginx/1.9.3
built by clang 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
built with OpenSSL 1.0.2a 19 Mar 2015 (running with OpenSSL 1.0.2c 12 Jun 2015)

If the running with OpenSSL statement specifies a vulnerable version (1.0.2c, 1.0.2b, 1.0.1n, or 1.0.1o), you need to upgrade. In versions of NGINX prior to 1.9.0, nginx ‑V doesn’t report the OpenSSL version, so you can use the instructions in this article.

Upgrading OpenSSL

NGINX typically uses the version of OpenSSL shipped with your operating system. Because the vulnerability was introduced very recently (June 2015), most released operating system versions are not affected. Follow your OS vendor’s instructions to update if required:

After upgrading the operating system OpenSSL library, restart your NGINX software.

If you have compiled NGINX yourself, you might have linked statically against your own OpenSSL libraries, in which case updating the operating system libraries has no effect on the version NGINX is using.

The output from nginx ‑V displays the compile‑time options you used, and the value in the running with OpenSSL field usually does not match the version of the library updated with the operating system (instead, it’s the one you linked against). In this case, you need to recompile NGINX and link against an updated version of OpenSSL to eliminate the vulnerability.

Hero image
Are Your Applications Secure?

Learn how to protect your apps with NGINX and NGINX Plus

About The Author

Owen Garrett

Sr. Director, Product Management

Owen is a senior member of the NGINX Product Management team, covering open source and commercial NGINX products. He holds a particular responsibility for microservices and Kubernetes‑centric solutions. He’s constantly amazed by the ingenuity of NGINX users and still learns of new ways to use NGINX with every discussion.

About F5 NGINX

F5, Inc. is the company behind NGINX, the popular open source project. We offer a suite of technologies for developing and delivering modern applications. Together with F5, our combined solution bridges the gap between NetOps and DevOps, with multi-cloud application services that span from code to customer.

Learn more at or join the conversation by following @nginx on Twitter.