Docker Community Forums

Share and learn in the Docker community.

Nginx SSL problem

Hi All,

I m having a problem with a very simple nginx docker implementation on a raspberry pi 2B. I’m trying to setup secure access via port 443, using self signed certs.
HTTP request [port 80] works fine; HTTPS gives " This site can’t be reached" alert.

Some details:
Raspberry Pi 2B - RaspOS
Docker & Docker Compose Installed
Created self signed Certificate with OpenSLL - privatkey and crt
Nginx container has 2 ports open : 80 and 443
Both ports are open and forwarded to the Rasp in my router
My domain name works in http access.

3 binded volumes:

  1. … : /etc/nginx/conf (contains nginx.conf)
  2. … : /usr/share/nginx/html
  3. … : /etc/nginx/certs

Loaded the certificates in the mounted volume
Specified the certificates container location (etc/nginx/certs/…) in the nginx.conf file.
Added the cert file to my Google Chrome on MacOS browser; and cleared the cache.
nginx container starts without errors, and I checked that the certificates are loaded into the container at the correct location in the container (etc/nginx/certs/…). So far so good I thought, but https access keeps producing the " This site can’t be reached" message.
Did I miss something?
PPee

Setting up an HTTPS Server
To set up an HTTPS server, in your nginx.conf file include the ssl parameter to the listen directive in the server block, then specify the locations of the server certificate and private key files:

server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
#…
}
The server certificate is a public entity. It is sent to every client that connects to the NGINX or NGINX Plus server. The private key is a secure entity and should be stored in a file with restricted access. However, the NGINX master process must be able to read this file. Alternatively, the private key can be stored in the same file as the certificate:

ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
In this case it is important to restrict access to the file. Note that although the certificate and the key are stored in one file in this case, only the certificate is sent to clients.

The ssl_protocols and ssl_ciphers directives can be used to require that clients use only the strong versions and ciphers of SSL/TLS when establishing connections.

Since version 1.9.1, NGINX uses these defaults:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
Vulnerabilities are sometimes found in the design of older ciphers, and we recommend disabling them in a modern NGINX configuration (unfortunately, the default configuration cannot easily be changed because of backward compatibility for existing NGINX deployments). Please note that CBC-mode ciphers might be vulnerable to a number of attacks (the BEAST attack in particular as described in CVE-2011-3389), and we recommend not using SSLv3 due to the POODLE attack, unless you need to support legacy clients.

OCSP Validation of Client Certificates
NGINX can be configured to use Online Certificate Status Protocol (OCSP) to check the validity of X.509 client certificates as they are presented. An OCSP request for the client certificate status is sent to an OCSP responder which checks the certificate validity and returns the response with the certificate status:

Good - the certificate is not revoked
Revoked - the certificate is revoked
Unknown - no information is available about the client certificate
To enable OCSP validation of SSL client certificates, specify the ssl_ocsp directive along with the ssl_verify_client directive, which enables certificate verification:

server {
listen 443 ssl;

ssl_certificate     /etc/ssl/foo.example.com.crt;
ssl_certificate_key /etc/ssl/foo.example.com.key;

ssl_verify_client       on;
ssl_trusted_certificate /etc/ssl/cachain.pem;
ssl_ocsp                on; # Enable OCSP validation

#...

}
NGINX sends the OCSP request to the OCSP URI embedded in the client certificate unless a different URI is defined with the ssl_ocsp_responder directive. Only http:// OCSP responders are supported:

#…
ssl_ocsp_responder http://ocsp.example.com/;
#…
To cache OCSP responses in a single memory zone shared by all worker processes, specify the ssl_ocsp_cache directive to define the name and size of the zone. Responses are cached for 1 hour unless the nextUpdatevalue in the OCSP response specifies a different value:

#…
ssl_ocsp_cache shared:one:10m;
#…
The result of the client certificate validation is available in the $ssl_client_verify variable, including the reason for OCSP failure.

Hi Lewish95,
Thanks for your reply. Based on you reply I added a chained key/certificate and changed the nginx.conf in:

events {}

http {
    server {
    listen 80;
    listen 443 ssl;

    server_name jphas.duckdns.org;

    root /home/pi/Nginx/Content/;

    ssl_certificate        /etc/nginx/certs/localhost.crt;
    ssl_certificate_key    /etc/nginx/certs/localhost.key;

    ssl_verify_client       on;
    ssl_trusted_certificate /etc/nginx/certs/chained_lh.pem;
    ssl_ocsp                on; # Enable OCSP validation
    }
}

But no result,
any ideas?
PPee

Hi All,
Still no progress in my efforts to get https access to my nginx docker implementation.
Can somebody explain how it should work. I seem to get a “not secure site” message, because when accessing the host it does not use the in the container installed certificates.
Any help please
PPee