Having issues setting up certbot --nginx for a vaultwarden docker container

Hello!

I'm trying to setup a vaultwarden docker-compose on my ubuntu server using nginx as a proxy.

I managed to get everything working on HTTP only. I was able to connect to my server using my domain DNS. This was my original config in

/etc/nginx/sites-enabled/default

server {
    listen 80;
    server_name 4968431.xyz www.4968431.xyz;

    location / {
        proxy_pass http://192.168.0.200:8000; # bitwarden server address
    }
}

after running the sudo certbot --nginx,
This is what the file looks like:

server {

        server_name 4968431.xyz www.4968431.xyz;

#       root /var/www/example.com;
#       index index.html;

        location / {
                proxy_pass http://192.168.0.200:8000; #bitwarden (vaultwarden)
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.4968431.xyz/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.4968431.xyz/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 {
   if ($host = www.4968431.xyz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = 4968431.xyz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        listen [::]:80;

        server_name 4968431.xyz www.4968431.xyz;
    return 404; # managed by Certbot
}

The website becomes unavailable afterwards.
I have Nginx Full enabled in my firewall and have tried restarting and reloading the nginx files with

sudo nginx -t && sudo nginx -s reload

and

sudo systemctl restart nginx

I don't really know what to do. I wonder if the updated file is not pointing to the right address anymore maybe.

Thanks,
Lucien


My domain is: 4968431.xyz

I ran this command: sudo certbot --nginx

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: 4968431.xyz
2: www.4968431.xyz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 
Requesting a certificate for 4968431.xyz and www.4968431.xyz

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/4968431.xyz/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/4968431.xyz/privkey.pem
This certificate expires on 2024-01-19.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for 4968431.xyz to /etc/nginx/sites-enabled/default
Successfully deployed certificate for www.4968431.xyz to /etc/nginx/sites-enabled/default
Congratulations! You have successfully enabled HTTPS on https://4968431.xyz and https://www.4968431.xyz

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version): nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 22.04.3 LTS

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.7.2

Can you explain what you mean by the site becomes unavailable?

I can connect to your site just fine but it currently is using an invalid cert.

Your site is currently using the most recently issued cert with just the www name in it (see below). So, when connecting using the root domain a browser will report security failure because the root name is not in the cert.

In general, whatever problem you are having is not related to getting certs. In fact, it is possible you are now rate limited because you got too many.

This SSL Checker site is a good one to test connections and see what cert is used. If you try it with both your domain names you will see www works but the root name fails validation.

Here is your cert history as known by the public transparency logs

3 Likes

hey, thanks for the quick response!

by "unavailable" I mean that whatever browser I use tries to connect for quite a long time and ends up timing out. My guess is that it can't establish a connection.

I'm definitely not understanding the internet protocol and SSL enough though :confused:

I wasn't aware of all these certs I was creating while trying to "troubleshoot" my problem.

Do you know how I could delete the duplicates?

when you said you can connect to my site, do you mean you get to the vaultwarden sign-up page that I'm hosting or just that you see that my site is up? I'm confused, sorry.

1 Like

I'd change:

To:

    if ($host = 4968431.xyz) {
        return 301 https://www.$host$request_uri;
    }

OR

Switch to using a cert that has both names on it [recommended]

2 Likes

I can connect to your domain and see your VaultWarden page

The SSL Checker site I linked to can reach your site just fine and so can SSL Labs (see your A score here)

You do have a cert problem and @rg305 showed a partial work-around for this problem. But, people using HTTPS to go directly to your root domain will still see a cert error (people use www should be fine). So, you should definitely fix that.

You may have some sort of connection issue from whatever device you are trying to use. Try a mobile phone with wifi disabled so use your carrier's public network.

4 Likes

ok I can indeed connect from my phone provider!
thanks for the heads-up :slight_smile:

For how I plan to use this website, I think it's no so bad if I leave it working with www, but I'm still wondering if there's a way to remove old duplicated certs?

or maybe I use

sudo certbot delete --cert-name example.com

and start again while including both @ and www in the same command.

It is noteworthy to mention that I've used that specific command a couple of times already while troubleshooting. I think it doesn't fully remove certs.. maybe I have to go through my domain provider? (namecheap)

1 Like

No, we can start by looking at what you have. Show us the output of this

sudo certbot certificates
3 Likes

allright, here it is:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: 4968431.xyz
    Serial Number: 33db8f54d24d7b73461efd3273e03c0c514
    Key Type: ECDSA
    Domains: 4968431.xyz www.4968431.xyz
    Expiry Date: 2024-01-19 18:40:28+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/4968431.xyz/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/4968431.xyz/privkey.pem
  Certificate Name: www.4968431.xyz
    Serial Number: 48e6803b69422531c84a12d32ae0c100e99
    Key Type: ECDSA
    Domains: www.4968431.xyz
    Expiry Date: 2024-01-19 18:41:16+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/www.4968431.xyz/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.4968431.xyz/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Two [separate] certs [of the same type(ECDSA) can't be served from one vhost].
That would require two [separate] vhosts to serve them from.

Since you are using one vhost with both names, you will need to use one cert with both names on it.

2 Likes

doesn't the first cert displayed have both domain included? maybe I could remove the other one?

Yes it does [I missed that detail].

Switch these lines:

To use these files instead:

And then:

  • restart the web service
    ensure that all that works as expected
  • [then] delete the unnecessary cert:
    sudo certbot delete --certname www.4968431.xyz
    [be forwarned: if you provided an email address, you will get expiry notices for that deleted cert]
    then recheck:
    sudo certbot certificates
    [to be sure]
3 Likes

ok I'll try that!
just to be sure, I should change only the respective PATH and keep the declaration in the lines right? I'm thinking:

ssl_certificate /etc/letsencrypt/live/4968431.xyz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/4968431.xyz/privkey.pem; # managed by Certbot
2 Likes

Just edit the vhost file and remove the two:
www.

3 Likes

Allright! It works wonderfully now, thank you so much!
The only problem is that I still can`t access the website from my own network. (both wifi and ethernet)

I tried restarting the router and the computer, clearing the browser cash, deleting the DNS on my computer and tried on chrome, firefox and brave.

Can you guys think of something I haven't tried?
On my phone's internet provider it works great though! :slight_smile:

2 Likes

It has to do with trying to access an IP that is on the Internet when it really isn't.
While you are on the same side of the NAT device.
So, you are asking to go outside to get to an IP [which is NOT really outside].
But that IP is being [supposed to be] NATted inwards.
If the NAT device [router] doesn't support these kinds of connections [hairpinning], then you won't be able to reach that site by that IP.

There is one way to handle this [even when the NAT device can't]:
Highjack the DNS entry and return the clients in that network the real IP.
Method #1:
You can do that by running your own caching DNS server and then override that specific entry there.
You would have to ensure all the clients use that DNS server instead of any other public DNS system.
That DNS server use can be forced in DHCP.
Method #2:
Modify the local hosts file in each of the clients that needs to directly access the IP.
'nix systems file: /etc/hosts
Windows systems file: %systemroot%\system32\drivers\etc\hosts
Add an entry to resolve the name to the internal IP.
Method #3:
Create a new network directly attached to the NAT device.
Move the server into that new network.
[that should force the NAT device to route it correctly (across) the router]

4 Likes

Could you give me an example of the second method involving editing the hosts? :slight_smile:
Also, how can I access locally while still being in https? I can't seem to make it work.

'nix:
vi /etc/hosts
add desired entry:
192.168.0.0 myserver.example.com
save file and close vi
[you can use any text editor you like]

Windows:
Open the file with notepad: %systemroot%\system32\drivers\etc\hosts
add desired entry:
192.168.0.0 myserver.example.com
save the file and close notepad.
If the file can't be saved in that folder [but you do have admin rights], then save it elsewhere.
Then rename it [notepad may insist on adding the ".txt" to newly saved files] if needed.
Then copy, or just move, it to the folder: %systemroot%\system32\drivers\etc\
It should prompt you - click yes to overwrite the file, etc.
If you DON'T have admin rights... that won't be possible to edit that file.

2 Likes

Locally from the same server?
OR
Locally from the same network [but from another device]?

3 Likes

from the same network but from another device

If your NAT device [router] doesn't support hairpinning*, you will need to apply one of those methods.

*Hairpinning: Network address translation - Wikipedia

2 Likes