Vm: Problem with creating LE-SSL Cert

[bobdig]

Steps to reproduce

1.Installed new ncvm today after fresh dl today
2.run it

Expected behaviour

It should create LE-SSL Cert

Actual behaviour

it is not doing it. Not in the initial setup process and not after manual start afterwards.

Is this correct?XXX ([y]es or [N]o): y
Checking if XXX exists and is reachable...
Doing a DNS lookup for XXX...
DNS seems correct when checking with nslookup!
DNS lookup failed with dig. The external IP (XXX) address of this serve r is not the same as the A-record.
Please check your DNS settings! Maybe the domain isn't propagated?
Please check https://www.whatsmydns.net/#A/XXX if the IP seems cor rect.
ncadmin@nextcloud:~$ Nope, it's not there. You have to create XXX and point

I use a subdomain (xxx.dyndns.org).
https://www.whatsmydns.net showed no problems.
Worked before. So there is something not ok.

[bobdig]

I was just curious, wanted to find out if the included setup for LE would allow for an wildcard cert, but it wont even do the setup, so I couldn't check it out at all. Would like to have such an option if possible, because I get my first own domain in a few days. ;)

[enoch85]

The script does checks to check if everything is prepared for the script to succeed. If things aren't setup correctly it will stop executing, by design.

That is so that you don't install any unnecessary packages, and is left with a failing setup. If the checks pass, it's almost guaranteed that it will work.

You could hash them out in the code just for testing though.

Wilcards should be supported with the DNS option which is implemented in the scripts as well.

[enoch85]

I can also add that I've made the checks stricter now than before, hence it might not proceed in some edge cases anymore.

[bobdig]

But I have no edge case, just a subdomain with dyndns. Tested it three times. Why you closed it?
I am a big fan of your work and recommend your vm when ever I can but how you handle issues is not ok. Last time I told you about a problem you sad you've tested it 5 times, 3 days later you apologized, because someone mailed you with the exact same problem...

[enoch85]

I was closing since the error says:

DNS lookup failed with X The external IP (XXX) address of this serve r is not the same as the A-record.

So in my world that means that the DNS isn't propagated yet.

The thing is also that I helped a customer yesterday with setting up SSL and it worked out of the box, and since nothing changed that tells me that it's a configuration issue on the end-users end.

I will run some tests and leave this open until I've confirmed it's working or not. Sorry for being so quick on the close button, I get theese types of reports from time to time, and in 99% of the cases, it's either:

1. Propagation not done yet
2. Some other error caused by the end-user.

[enoch85]

This is the logic if you want to test for yourself. Thanks. :)

[bobdig]

-not relevant-

[enoch85]

OK, so can you post the result of: http://mittip.se?

[bobdig]

-not relevant-

[bobdig]

-not relevant-

[enoch85]

What happens if you comment out (put a # in front) the test and run the script?

You can check open ports here: https://www.yougetsignal.com/tools/open-ports/, it seems like they are open and the script should recognize that in the second test.

[enoch85]

Also, since the IP now seems to be propagated, could you please test the original script "as is" just to check if the original issue was a propagation issue?

Thanks.

[bobdig]

What happens if you comment out (put a # in front) the test and run the script?

Hard for me to do, to be honest. Don't have the right to replace it. It also looks different then the link you gave before.

Also, since the IP now seems to be propagated, could you please test the original script "as is" just to >check if the original issue was a propagation issue?

It doesn't do it.

But there is one more thing I forgot to mention. Many Cable-ISP do, and so does mine, some sort of NAT, so that the Router can not see the external WAN-IP, but a 100.6something IP. So if your script also checks against the router, it will fail. But I as a user can open Ports with no problem. You can believe me, I am happy nextclouding with your vm for years and have no problem with WAN-Access. I can bring my original nextcloudingVm up, if you don't believe it. But I see, the new one is already up and reachable but without SSL. ;)

[enoch85]

It would be (is) hard to programmatically ensure that every single router on the planet works with the scripts with no user interference. Sure, maybe program a DynDNS service would work - but my time is limited. I don't even know if there are any DynDNS with an API that supports account registratation with some bash scripts, would have to investigate that.

As it is now it works with the most setups, I just tested on DigitalOcean (which I use as a reference) and it setup without any issues at all. So in my world there are no script error per say, more like a limitation on the end-users side, or that something is wrong in the end-users setup. IN your case it seems to be a limitation.

That said, if your ISP is blocking you in some way, I'm sorry. Change ISP ;). Jokes aside, the script isn't designed to handle edge cases like yours. I think it would be possible to solve, but that would require some support.

[bobdig]

What happens if you comment out (put a # in front) the test and run the script?

I think I made it, now the script is running.

[bobdig]

It would be (is) hard to programmatically ensure that every single router on the planet works with the scripts with no user interference. Sure, maybe program a DynDNS service would work - but my time is limited. I don't even know if there are any DynDNS with an API that supports account registratation with some bash scripts, would have to investigate that.

As it is now it works with the most setups, I just tested on DigitalOcean (which I use as a reference) and it setup without any issues at all. So in my world there are no script error per say, more like a limitation on the end-users side, or that something is wrong in the end-users setup. IN your case it seems to be a limitation.

That said, if your ISP is blocking you in some way, I'm sorry. Change ISP ;). Jokes aside, the script isn't designed to handle edge cases like yours. I think it would be possible to solve, but that would require some support.

The only problem is that your script is checking against the router I think. It didn't do it before. So I think it would be easily "fixable".

[enoch85]

I think I made it

Great! :+1:

It would be interesting to see the actual output of the domain_check looks like.

The only problem is that your script is checking against the router I think. It didn't do it before. So I think it would be easily fixable.

Yeah, the check is more strict now.

[bobdig]

It would be interesting to see the actual output of the domain_check looks like.

I don't know what you mean by that. I commented out the right thing it seems.
Your VM is the only hope for many novice user like me, so I hope you fix that problem which some of us do and will have.

[enoch85]

You don't have a valid SSL cert yet. Just checked.

[enoch85]

Email me your Teamviewer details and I'll have a quick look.

github at hanssonit dot se

[bobdig]

Did it.

[enoch85]

The dig test failed since it resolves the actual IP of the host it fails when using DynDNS.

So the script does what it's intended to do.

Will add some info about when using DynDNS.

[bobdig]

@enoch85 I don't think so, the problem is not the use of dyndns-DDNS but that my ISP is doing that kind of NAT with the 100.65.. IP.
But thanks for looking into it. I hope you will get to that.

[bobdig]

And please delete this, thanks again.

[enoch85]

Yes, the issue is DynDNS. Check your DNS IP now, it's different. :)

The script checks if the WAN IP (your external IP in your router) is the same as the DNS A record, if not, then it "fails".

I'm looking into now if this can be improved.

[bobdig]

And again, no. I deliberately changed my WAN-IP (eg. 5.x.x.x) but what my router is seeing is not my WAN-IP, it is an CGN-IP (100.65.x.x) from my ISP, which is again, not my WAN-IP. So it differs and that is the problem or to be more precise, that the new script is checking and that that CGN-IP is also reported. But that has nothing to do with DDNS in general.

[enoch85]

The current solution is to hash out the check if you are running DDNS, but I will make it optional if it fails instead. Working on it right now.

Had another support session recently with the same error.

[bobdig]

Anyhow, if it will work, perfect. 🥇