Certbot failed to authenticate using SWAG

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: see below

I ran this command: docker-compose up -d

swag: # Docker Hub
image: Package swag · GitHub #swag, formerly known as letsencrypt (see: Introducing SWAG - Secure Web Application Gateway | LinuxServer.io)
#image: certbot:1.32.0-ls163 (bug in certbot 2.0)
container_name: swag # Secure Web Application Gateway (SWAG)
cap_add: # add container capability: NET_ADMIN
- NET_ADMIN # for Fail2Ban
environment:
- PUID=1001 #change PUID if needed: xxxx
- PGID=100 #change PGID if needed: users
- TZ=America/Chicago # change Time Zone if needed
- URL=duckdns.org #insert your domain name - yourdomain.url
- SUBDOMAINS=x7qzbj0fq9, # will try to get cert with subdomain & without
- VALIDATION=http
- EMAIL=???@gmail.com # define email; required to renew certificate
- ONLY_SUBDOMAINS=true #optional
network_mode: appuser_remote
volumes:
- /srv/dev-disk-by-uuid-xxx/appdata/swag:/config #/srv/dev-disk-... needs to be adjusted
ports:
- 444:443
- 81:80
restart: unless-stopped

It produced this output:
Account registered.
Requesting a certificate for x7qzbj0fq9.duckdns.org

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: x7qzbj0fq9.duckdns.org
Type: connection
Detail: 107.133.117.222: Fetching http://x7qzbj0fq9.duckdns.org/.well-known/acme-challenge/lk8yJROx6CJTgdy8paYreIJy1i0wT1F_rOOZ09KITQs: Timeout during connect (likely firewall problem)

My web server is (include version):

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

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): docker

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

This is not a firewall problem. If I stop swag and start nginx on the same port 81:80, I get a response from nginx. It doesn't matter if I access it locally, using the IP, or through duckdns. With nginx running, port 80 is open (nmap). With swag running, port 80 is closed. I believe, when I tried one time, soon after swag start, port 80 did respond. A little later it closed. Some configuration is causing this to fail.

authenticator: standalone >> does something need to be set in a file?

Any suggestions will be greatly appreciated.
Thanks.

2

I tried the following changes to teh docker compose file:

version: "2"
services:
swag: # Docker Hub
image: Package swag · GitHub #swag, formerly known as letsencrypt (see: Introducing SWAG - Secure Web Application Gateway | LinuxServer.io)
#image: certbot:1.32.0-ls163 (bug in certbot 2.0)
container_name: swag # Secure Web Application Gateway (SWAG)
cap_add: # add container capability: NET_ADMIN
- NET_ADMIN # for Fail2Ban
environment:
- PUID=1001 #change PUID if needed: ???
- PGID=100 #change PGID if needed: users
- TZ=America/Chicago # change Time Zone if needed
- URL=x7qzbj0fq9.duckdns.org #insert your domain name - yourdomain.url
- SUBDOMAINS=wildcard, # will try to get cert with subdomain & without
- VALIDATION=duckdns #http
- DUCKDNSTOKEN=??????? #optional
- EMAIL=???@gmail.com # define email; required to renew certificate
- ONLY_SUBDOMAINS=false #optional
- STAGING=false #optional
network_mode: appuser_remote
volumes:
- /srv/dev-disk-by-uuid-xxx/appdata/swag:/config #/srv/dev-disk-... needs to be adjusted
ports:
- 444:443
- 81:80
restart: unless-stopped

This resulted in:

Variables set:
PUID=1001
PGID=100
TZ=America/Chicago
URL=x7qzbj0fq9.duckdns.org
SUBDOMAINS=wildcard,
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=duckdns
CERTPROVIDER=
DNSPLUGIN=
EMAIL=???@gmail.com
STAGING=false

the resulting certificate will only cover the main domain due to a limitation of duckdns, ie. subdomain.duckdns.org
Using Let's Encrypt as the cert provider
No subdomains defined
E-mail address entered: ???@gmail.com
dns validation via duckdns plugin is selected
Different validation parameters entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account registered.
Requesting a certificate for x7qzbj0fq9.duckdns.org
Waiting 30 seconds for DNS changes to propagate

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/x7qzbj0fq9.duckdns.org/fullchain.pem
Key is saved at: /etc/letsencrypt/live/x7qzbj0fq9.duckdns.org/privkey.pem
This certificate expires on 2023-02-25.
These files will be updated when the certificate renews.
NEXT STEPS:

  • The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See User Guide — Certbot 2.0.0 documentation for instructions.

If you like Certbot, please consider supporting our work by:

New certificate generated; starting nginx
cont-init: info: /etc/cont-init.d/50-certbot exited 0
cont-init: info: running /etc/cont-init.d/55-permissions
cont-init: info: /etc/cont-init.d/55-permissions exited 0
cont-init: info: running /etc/cont-init.d/60-renew
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
cont-init: info: /etc/cont-init.d/60-renew exited 0
cont-init: info: running /etc/cont-init.d/70-outdated
cont-init: info: /etc/cont-init.d/70-outdated exited 0
cont-init: info: running /etc/cont-init.d/85-version-checks
cont-init: info: /etc/cont-init.d/85-version-checks exited 0
cont-init: info: running /etc/cont-init.d/99-custom-files
[custom-init] No custom files found, skipping...
cont-init: info: /etc/cont-init.d/99-custom-files exited 0
cont-init: warning: some scripts exited nonzero
s6-rc: warning: unable to start service legacy-cont-init: command exited 1
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service 00-legacy: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service 00-legacy successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Looks like a success. I can access swag from the browser using the DuckDNS url.

nmap shows ports 80 and 443 are open.
Why can I not use VALIDATION=http?
What are the configuration requirements?
can I use No-IP (ddns.net) instead of DuckDNS?

Thanks.

1 Like
3

Do you mean if you stop the docker container and run nginx on the host it works? Or, are you saying if you run nginx in the container configured with port 81:80 nginx works?

Should it be working now? Because I can't reach it from my own test server and Let's Debug test site (here) doesn't see it either.

3 Likes
4

I have 2 containers for the test; swag and nginx. They both use ports 81:80. I run only one at a time. Using VALIDATION=http did not succeed, so swag left the ports closed, since its instance of nginx was not started. The independent nginx had no problem responding to port 80 requests.

You will not be able to reach it. It is behind a pfSense firewall using a VPN exit. The OMV instance (a KVM guest VM) bypasses the VPN going out, so it can respond directly to requests coming in on the ISP IP. However, I have a rule only allowing the VPN host IP back in on ports 80 & 443. So, I can get to swag from my browser, but no one else, at this time.

So, the remaining question is, why can I not create a cert using http validation in swag?
Currently, I also cannot get to nextcloud through swag. It is not forwarding. The standard swag welcome webpage appears for the site URL alone (https). Adding /nextcloud, times out.

5

I think I see. If the validation process on port 80 is a reply to a request, it should come through the firewall. If it is an independent (uninitiated) request, the firewall will block it. I would need to know the IP address of the validation server to allow it through the firewall. The same applies for Let's Debug. Without allowing the IP address it uses for the test, the firewall will block. I guess I need to open up the access for at least port 80 to any address. Right?

6

Yes. See

And also this on Let's Encrypt Server IP addresses

4 Likes
7

Thank you. Very helpful. DuckDNS validation appears to have worked without port 80 being open. It appears that No-IP can be used as a DDNS, however, only using http validation, since it does not have the required API. Makes sense now.
I agree with the port 80 practice for a public webpage. Anyone probing ports will always try 80 and 443 anyway.

Is there an image to use in Docker to maintain the certificate, to isolate the validation information (like API credentials) from the SWAG container?

Thanks.

1 Like
8

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