Is it possible to encrypt multiple ports on the same domain

Help
1

Setup

  1. Cloud Instance Ubuntu 18.04 - Nginx Reverse Proxy + Certbot
  2. Docker (Hosting Python Flask Website on Port 3389)
  3. Docker (Hosting Jenkins on Port 8080)

I've successfully setup HTTPS SSL on the Flask Website but am having issues trying to do the same on port 8080 for the Jenkins web server.

I've tried adding listen 8080 ssl in the server {} and adding an extra location / { proxy_pass http:localhost:8080;} both didn't work. I didn't add another server {} block as both ports are under the same domain/ip.

nginx. conf virtual host

    server {
            server_name samplewebsitename.net;
    location / {
            proxy_pass http://localhost:3389;
            }
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/samplewebsitename.net/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/samplewebsitename.net/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

Is the configuration I'm trying to do possible? If it is, would appreciate assistance for the nginx.conf
Thanks in advance!

2 Likes
2

Yes. The Let's Encrypt certificate can be used for any port you'd like.

Well, I'm not sure if this is the correct Community to ask this, as this isn't a TLS or Let's Encrypt specific issue, but more a generic "How do I set up a reverse proxy with nginx" question in my opinion.

But I'm willing to give a hint: you can't let nginx listen on port 8080 and have your Jenkins listen on the same port (unless you're using different IP addresses). I'm also not sure why you'd like to have nginx listen on port 8080? The idea behind the reverse proxy is to let users connect to the same IP + port, but connect to different backends according to hostname and/or path?

2 Likes
3

Its my first time doing custom configurations as I normally just create and deploy applications with the default settings as proof of concepts for school projects. Didn't know about the conflict from having docker and nginx using the same port but what you said make sense. Thanks for your hint!

2 Likes
4

Allow me to list out the possible configurations; so that this may become more clear.

If both services will be behind the same reverse proxy (with only one external IP) then your four "separation" choices are.

  • use the same FQDN with different external ports: [same|different]
    name1:port123 proxies to service1
    name1:port345 proxies to service2

  • use different FQDNs but same port: [different|same]
    name1:port123 proxies to service1
    name2:port123 proxies to service2

  • use different FQDNs and different external ports: [different|different]
    name1:port123 proxies to service1
    name2:port345 proxies to service2

But this isn't possible:

  • use the same FQDN and the same port for two different things. [same|same]
    name1:port123 proxies to service1
    name1:port123 proxies to service2
2 Likes
5

Actually while playing devil's advocate and rereading my own post, I've noticed that there may be a way to use the same FQDN and port to do two (or more) completely separate things!

It is possible when a third differentiator is included.
Like: [same|same|different]
https://name1:port443/folder1/ proxies to service1
https://name1:port443/folder2/ proxies to service2
or more exemplary:
https://samplewebsitename.net/ proxies to a secure WEB service
https://samplewebsitename.net/RDP/ proxies to RDP service
https://samplewebsitename.net/JENKINS/ proxies to JENKINS service

2 Likes
6

Indeed, you can use separate proxy_pass directives in different location blocks.

3 Likes
7

I wanted to that but I'm not sure what to use for folder1/folder2 when specifying location /folder1 {proxy_pass:xxxx} as I'm using docker containers.

I created another server block with port 8081 as SSL to proxy to 8080 Jenkins docker as Osiris mentioned that Nginx and the docker can't listen on the same port.
nginx.conf
# Virtual Host Configs ##

    server {                
    server_name samplewebsitename.net;
    location / {
            proxy_pass http://localhost:3389;
            }
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/samplewebsitename.net/fullchain.pem; # managed by Certbot  
ssl_certificate_key /etc/letsencrypt/live/samplewebsitename.net/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

    server {
            server_name samplewebsitename.net;
    location / {
            proxy_pass http://localhost:8080;
            }
listen 8081 ssl; # managed by Certbot    ssl_certificate /etc/letsencrypt/live/samplewebsitename.net/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/samplewebsitename.net/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

https://samplewebsitename.net:8081 doesn't work. I've read up on RP guides, some create another .conf file(s) in /sites-available while some just edit the nginx.conf,might try the /sites-available method soon

1 Like
8

If you want to do this:

Then you only need one server block.
And as @Osiris spelled it out:

You only need to add multiple location blocks (within that single server block) to make this work.
Like:

    location /RDP {
            proxy_pass https://localhost:3389;
            }
    location /JENKINS {
            proxy_pass http://localhost:8080;
            }
    location / {
            proxy_pass http://localhost:80;
            }

I don't know your system, so that is merely an example of HOW this can be done.
So, you should only make changes that fit your system and your needs.
You should always understand what you are doing and never just follow anyone's advice/guide blindly.

1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.