mattie112

Random one from me get's an A, headers are usually sent by your application so I would check there first.

It is not clear to me (also in the original post). Is this the Nginx from NPM logging this? Or unraid? if you stop the NPM docker container does the log continue? If it does than it has to be reported to the Unread team.

I have my NPM container running in network "br0" so I can use an IP from my routers 'range'. Then I can use that IP to forward traffic to whatever port (including 80/443)

Good luck, let us know

I don't use CF so please check their forums. Either they cache it incorrectly (as it will create a new file to verify each time) or they block http/port 80.

This exactly the error as the previous 10 posts Make sure your website works for the .well-known folder on unsecured http port 80. If you have cloudflare see the post above. This really says it all: Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems: Domain: nextcloud.myserver.com Type: unauthorized Detail: 2606:4700:3034::6815:31d8: Invalid response from http://nextcloud.myserver.com/.well-known/acme-challenge/B2MWRSrn1NaJZaqWPpd4YVrWrBoqB1U11L4iIWluKFw: 403 Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Or use DNS authantication for letsencrypt Or possible: https://community.letsencrypt.org/t/cloudflare-blocking/180172/5

I don't use CF myself. But you need to be sure that the .well-known directory can be reached over unsecured http port 80

Try running certbot manually with some debug flags (-v) and see what it does.

I was talking about viewing the certificate (details) with your web browser. But good that it is working now

Yes for example, just to pull the certificate and to make sure it is what you expect. If you see that it is expired for example you know to start with the renewal process. If it is valid then start at CF.

Can you try to access your website directly? I don't use cloudflare but perhaps you can see the certificate there? If you don't know what certificate your website serves it is hard to debug from here. Perhaps you can "pause" cloudflare and then test your website here: https://www.ssllabs.com/ssltest/

Last time I checked it was hardcoded to port 443 (and 8080). I also changed this due to having IPv6 with no NAT so I needed it to run on those ports. https://github.com/jlesage/docker-nginx-proxy-manager/blob/master/src/nginx-proxy-manager/build.sh#L150 Feel free to use my fork that only has the ports changed. https://github.com/Mattie112/docker-nginx-proxy-manager If I'll remember to do it I will update/merge it again somewhere this week

You can try to run certbot manually to get some more debugging info.

Just use any of the older tags: https://hub.docker.com/r/jlesage/nginx-proxy-manager/tags

Confirm that your DNS is set-up correctly with a tool like: https://www.whatsmydns.net/ Confirm that your PC resolved the domain to the correct IP (for example by doing a ping or traceroute). Try it from a different device -> if it works there check your local PC for firewall for issues Try it from a different internet connection -> if it works check your modem/router firewall for issues

All domains must point to your IP. You can use a CNAME or an A record. This is unrelated to NPM. So what exactly is your question/problem?

The log file lists it already: "detail": "DNS problem: NXDOMAIN looking up A for dom.main-name.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for dom.main-name.com - check that a DNS record exists for this domain", Please confirm that your DNS is correctly set-up.

Well the error is that your disk is full. At your docker settings (advanced) you can see how much space there is left in your docker volume. I would suggest to check that first.

Try it from a different PC / browser. Try to 'ping' it to see if it resolves correctly. Does not look like a NPM problem to me as NPM has nothing to do with DNS.

And just for reference a 3rd datapoint: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: GenuineIntel BIOS Vendor ID: Intel Model name: Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz BIOS Model name: Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz Fill By OEM CPU @ 2.0GHz BIOS CPU family: 205 CPU family: 6 Model: 60 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Stepping: 3 CPU(s) scaling MHz: 93% CPU max MHz: 3000.0000 CPU min MHz: 800.0000 BogoMIPS: 3999.91 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc ar ch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4 _1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexprior ity ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d Virtualization features: Virtualization: VT-x Caches (sum of all): L1d: 128 KiB (4 instances) L1i: 128 KiB (4 instances) L2: 1 MiB (4 instances) L3: 6 MiB (1 instance) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-3 Vulnerabilities: Itlb multihit: KVM: Mitigation: Split huge pages L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled Mds: Mitigation; Clear CPU buffers; SMT disabled Meltdown: Mitigation; PTI Mmio stale data: Unknown: No mitigations Retbleed: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected Srbds: Mitigation; Microcode Tsx async abort: Not affected

Please confirm that your IP / open ports are correct. Can you access http://your.ip (from an EXTERNAL connection) would be a place to start. Just to confirm that everything other then NPM is working.

Nginx wants to load a certificate that does not exist. You can go into the console and run certbot --renew (or something) to fetch new certificates. It might be needed to first remove the SSL config so that nginx start. Or possible you can create an empty file (or self-signed cert) so that it at least loads.

Can you first try it without Cloudflare? Just point directly to your IP. If that does not work it is something with your NPM. If it does work it is something with cloudflare.

The flow is like this: - you request a certificate for domain.com (by asking letsencrypt (LC) to do that) - LC gives you a code (that is put in the .well-known dir) - LC does a DNS request for your domain.com to get the IP - LC connects to that domain/IP on port 80 (because: you don't have a certificate yet, so port 80 must be HTTP not HTTPS) - LC verifies that you "own" the domain by reading the code from the .well-known dir - LC supplies you with a certificate In this case the error is that is cannot verify the code, why I don't know it could be any of the previous steps. But: usually your NPM cannot be accessed over unsecured HTTP port 80.