8000 Multiple hosts defined, second one does not get https config in /etc/nginx/conf.d/default.conf · Issue #2023 · nginx-proxy/nginx-proxy · GitHub
[go: up one dir, main page]
Skip to content

Multiple hosts defined, second one does not get https config in /etc/nginx/conf.d/default.conf #2023

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ilium007 opened this issue Jul 18, 2022 · 8 comments
Open

Multiple hosts defined, second one does not get https config in /etc/nginx/conf.d/default.conf #2023

ilium007 opened this issue Jul 18, 2022 · 8 comments

Comments

@ilium007
Copy link
ilium007 commented Jul 18, 2022 •
edited
Loading

I have defined a second domain name in the Docker VIRTUAL_HOST env variable and I am not getting https for it.

When I check the /etc/nginx/conf.d/default.conf file I see the config

	# paste.xxx.dev
upstream paste.xxx.dev {
        ## Can be connected with "docker_debian03_net" network
        # privatebin
        server 172.16.241.3:8080;
}
server {
	server_name paste.xxx.dev;
	listen 80 ;
	access_log /var/log/nginx/access.log vhost;
	location / {
		proxy_pass http://paste.xxx.dev;
}
}
	# paste.xxx.yyy.dev
upstream paste.xxxyyy.dev {
        ## Can be connected with "docker_debian03_net" network
        # privatebin
        server 172.16.241.3:8080;
}
server {
	server_name paste.xxx.yyy.dev;
	listen 80 ;
	access_log /var/log/nginx/access.log vhost;
	# Do not HTTPS redirect Let'sEncrypt ACME challenge
	location ^~ /.well-known/acme-challenge/ {
		auth_basic off;
		auth_request off;
		allow all;
		root /usr/share/nginx/html;
		try_files $uri =404;
		break;
	}
	location / {
		return 301 https://$host$request_uri;
	}
}
server {
	server_name paste.xxx.yyy.dev;
	listen 443 ssl http2 ;
	access_log /var/log/nginx/access.log vhost;
	ssl_session_timeout 5m;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;
	ssl_certificate /etc/nginx/certs/xxx.dev.crt;
	ssl_certificate_key /etc/nginx/certs/xxx.dev.key;
	add_header Strict-Transport-Security "max-age=31536000" always;
	location / {
		proxy_pass http://paste.xxx.yyy.dev;
}
}

docker-compose.yml

version: "3.9"
services:
  privatebin:
    container_name: privatebin
    image: privatebin/fs
    volumes:
      - /data/docker/privatebin/data:/srv/data
    environment:
      - TZ=Australia/Sydney
      - PHP_TZ=Australia/Sydney
      - VIRTUAL_HOST=paste.xxx.yyy.dev,paste.xxx.dev
      - VIRTUAL_PORT=8080
    networks:
      - debian03_net
    #ports:
      #- 8080:8080
    restart: unless-stopped

  nginx-proxy:
    container_name: nginx-proxy
    image: jwilder/nginx-proxy
    ports:
      - 80:80
      - 443:443
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /data/docker/certs:/etc/nginx/certs
    networks:
      - debian03_net
    restart: unless-stopped

networks:
  debian03_net:
    ipam:
      driver: default
      config:
        - subnet: 172.16.241.0/24

This line is causing the issue:

- VIRTUAL_HOST=paste.xxx.yyy.dev,paste.xxx.dev

The paste.xxx.dev only gets a port 80 definition and no port 443 config.
@Pearseak
Copy link

same issue here

@sameeraksc
Copy link

Same issue here @buchdag

@sameeraksc
Copy link

@ilium007 @Pearseak Guys I fixed this issue after updating the docker-composer.yaml version to version: '2'. previously I used 3.9

@Csardelacal
Copy link

@ilium007 @Pearseak Guys I fixed this issue after updating the docker-composer.yaml version to version: '2'. previously I used 3.9

That's cool, but also hardly a solution. Version 2 is a very old version by today's standards. I think it should work without it requiring a downgrade there.

@sameeraksc
Copy link

yeah that's correct

@oliv3r
Copy link
oliv3r commented Jul 12, 2024 •
edited
Loading

Since this issue is still open, and I ran into this (for different reasons as well) I think it's worth a bump.

What happens for me, is that I added a new domain to an existing container via VIRTUAL_HOST. Next, I wanted to run certbot to generate a new certificate. This fails, because well-known is redirected to the https host.

I think it's fair, either via a flag to always noredirect well-known/acme-challange. I think it's quite reasonable that the acme-challange is always accessible under http; or is there a https use-case?

Setting the HTTPS_NOREDIRECT flag on the container is not idea, because then all https is no longer redirected ...

P.S. I only use the nginx.tmp from this repo; I use manual docker-gen

@buchdag
Copy link
Member
buchdag commented Jul 14, 2024

@oliv3r which version of the template are you using ? Since 1.6 it should behave as you describe and always handle ACME challenge location / never redirect ACME challenge to HTTPS, unless you explicitly disable ACME challenge location handling (either globally or per vhost).

See #2446 and #2468 for more details.

@oliv3r
Copy link
oliv3r commented Jul 24, 2024 •
edited
Loading

#buchdag Goog question, I've used master from a few months ago. The template isn't released in some consumable form, so I have to copy/paste it :( But if you state it was fixed already, I'll download it again and compare things :) Thank you for pointing this out!

(I'll close this issue once I can confirm this)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@ilium007 @Csardelacal @oliv3r @buchdag @Pearseak @sameeraksc
0