mattie112

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.

So the error is clear: 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. You have to make sure that port 80 (with no SSL) can be reached from the outside. Please confirm that that is the case.

Well without logs your guess is as good as mine. There is "somekind" of error!

Yes that should work just fine. On what action do you get the 400 error? Adding the host or enabling SSL? You could try to remove all files in appdata and start fresh if you have nothing on it just to make sure nothing "strange" happend during initial setup. Or go to the console of NPM and try a couple of `certbot` commands to manually get a SSL certificate (I don't know the exact commands) and see if that works or if that possible gives an error that you can search for.

Hm that is a strange error, afaik it should not "stop" if it cannot create a SSL certificate. What you can try is to first add a host without SSL and make sure that works. At least you know NPM works then.

A fun small experiment would be the following: edit C:\Windows\System32\drivers\etc\hosts (use notepad in administrator mode) add the following INTERNAL.ip.of.nginxdocker your.nextcloud.hostname (so for example 192.168.1.123 nextcloud.foo.bar) Then try to see what happens. You have now "excluded" the entire DNS part as your (and only your) computer now "forces" the specified domain to the specified IP. If it works: you have an issue with your DNS provider. If it doesn't, it is something with NPM

I guess if you have multiple external IPs you could enable the forward only for one IP? But you will have to consult your router manual/docs for that. Or just use 0.0.0.0 - 255.255.255.255 to see if that works

Can you check the nginx log to see why it crashes? Or is there no log.

A few post back someone else also said it took some time. Possible caching or rate limit? Was nginx crashing due to missing certificates? Possible you where restarting while certbot was doing its job? For me I had 0 issues in the last years. As long as you keep port 80 correctly open the Cerificates should be renewed just fine. Ofc always recommend to add an alert on your certs if you rely on them.

I think there is also a sqlite database? Or backup the entire folder from app data to be safe.

A random online port scan on the IP from the A record of the domain you provided lists port 80 as CLOSED. Letsencrypt needs this port to be open. Please double check this, really the last 10 pages of this topic is not issues with NPM but some issue with connectivity. And also I'm on holiday with only my phone so I don't have any tools to easally check things.

Yes correct, but confirm from an external point of view (phone with mobile date) that that works