server.crt
and server.key
should be the paths to your certificate and your private key, respectively.
X-Real-IP is the IP of the client connected to the proxy. It is important to use it when you need to retrieve the IP of the connected client, otherwise you will end up with the IP of the proxy. You should check your application server API on how to set it (desirable) or retrieve it from the request headers.
You MUST use CA signed certificates on production environment.
Let's Encrypt is a new project that will be launched on 2015 Q4 that promises to allow you to get trustworthy certificates for free.
From now, rely on commercial ones like DigiCert, Comodo, or GoDaddy.
Instead of relying on the application server I would deploy the HTTPS on a load balancer working as a reverse proxy in front of it.
The benefits are mostly higher performance and increased security (abstracting / isolating the private key from the application).
When you use TLS there is a subtle, but noticeable impact for each request caused by the TLS handshake. With a reverse proxy approach we can avoid having this impact influence directly to the application servers.
Besides it, we can deploy HTTP2-enabled reverse proxy so instead of having a negative impact on performance due to the added layer we will end up having a positive one on clients that already support the new version of HTTP.
For that I recommend using nginx. I have set up a configuration template you can easily adapt to your needs.
- WebSocket proxying on nginx
- NGINX Open Source 1.9.5 Released with HTTP/2 Support
- nginx reverse proxy guide
- nginx: HTTP/2 for Web Application Developers
- High Performance Browser Networking: Chapter 12. HTTP/2
I also recommend also setting HSTS for improved security, but be sure to get everything else right first:
- HSTS Preload Submission list
- Setting up HSTS in nginx
- [OWASP: HTTP Strict Transport Security]https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
- Wikipedia: HTTP Strict Transport Security