SSL not working when using IP address?

[Mavrik347]

Hello all,

I've setup nginxproxy for 2 containers, one of which is using SSL. When going to https://dnsname it loads fine, when using https://ipaddress it gives ERR_SSL_PROTOCOL_ERROR. I need to use the IP due to DNS complications at one of our other locations.

dnsname.key and dnsname.crt exist in /etc/nginx/certs/ and in the target container
cert is self-signed and has IP.1 and DNS.1 in the san.cnf
IP.1 in the certificate is the IP of the physical host which all 3 containers live on, though I have tried with the docker IP too as IP.2.

Both the IP and the name show as server_name's on docker exec nginxproxy nginx -T with the correct certificate paths for both.
docker-compose:

version: '3.9'
services:
marty:
image: marty
container_name: marty
build:
context: ./
dockerfile: host.dockerfile
working_dir: /var/www
volumes:
- ./html:/var/www/html
environment:
- VIRTUAL_HOST=marty,192.168.3.14
- VIRTUAL_PROTO=https
- VIRTUAL_PORT=443
- CERT_NAME=marty
networks:
- nginx-proxy
restart: unless-stopped
networks:
nginx-proxy:
external: true

I've been trying for a few days and cannot work out why it's working when I use the name but not the IP. Anyone have a clue or is it a bug?

[buchdag]

Hi.

Have your tried to also mount the certificate and private key as 192.168.3.14.crt and 192.168.3.14.key ?

[Mavrik347]

Hi, sorry about the slow reply. Yeah that's the first thing I did before using the ENV to declare the file.

Can you just clarify, are you supposed to run nginxproxy then run the containers or reboot nginxproxy each time a container is relaunched?

[buchdag]

Can you just clarify, are you supposed to run nginxproxy then run the containers or reboot nginxproxy each time a container is relaunched?

nginx-proxy is supposed to pick up changes automatically each time a container start, stop or restart.

I'll try to look into this but to be honest using IPs as VIRTUAL_HOST isn't an advertised and / or supported feature, it just happens to work "by accident". The fact that it's used to demonstrate wildcard host was rather a poor choice of example than a statement about actively supporting this.

[Mavrik347]

A bit more on this, I managed to fix it.

Firstly despite the VIRTUAL_HOST declaring the IP being used to reach it along with the certificate in CERT_NAME. nginxproxy uses the default.crt. If it doesn't exist, then you straight up get ERR_SSL_PROTOCOL_ERROR blocked.

So I generated a new SSL certificate. I took a carpet bombing approach, adding the DNS name, the IP used to reach it and a whole range of docker IP's as that's what comes up as the REMOTE_ADDR and SERVER_ADDR's via PHP. I put a few docker IP's in as they may change.

I then made that .crt the new marty.crt and default.crt and rebooted nginxproxy. Once the new certificate was installed on the end user devices the connection is accepted with no SSL warnings.