My certificate through letsencrypt has expired, and it fails verification when I try to renew. The error is “connection refused”. When I try to access the server on port 80, it immediately redirects to 443, and I think this is why (certbot uses port 80 to verify). Does anyone know where to look to allow port 80 to connect? Thanks.
Hi @anon23411752 AFAIK both 80 and 443 TCP should be reachable from internet to allow let’sencrypt certificate challenge and verify.
If both ports can be contacted from internet AND Let’sencrypt verification sites, the verification succeed and renew is done.
So… what could not allow the verification in your setup? Tell the community a bit more about that…
That is what I’m trying to figure out. If I access the site via VPN, port 80 is redirected to port 443. I did not set it up to do that, so I’m trying to figure out what would be causing the redirect.
Hi
NethServer wiill generally redirect ALL traffic with http / https to 443 (https).
This is standard here!
Note: LE can still access the “check” using http.
Works for me.
My 2 cents
Andy
The same, for at least 15-20 servers exposed on internet.
Without a bit more information about your server and how it’s installed and configured, community cannot help you.
This because, as community experience reported, if the documentation is followed, mechanism works.
1 Like
No, that isn’t why. A redirect will not cause “connection refused”; it will simply redirect, and Let’s Encrypt should follow that. To give more clarity on that “should”, LE will follow a HTTP redirect (i.e., a 301 redirect) to a FQDN (not an IP address) on port 80 or 443 (not on any other port).
So, how did you get the cert in the first place? Did you use the built-in feature (“Certificates” in the server manager)? Through some other invocation of certbot at the command line? Or in some other way (and if so, what?)
If you used certbot (which includes the built-in feature), take a look in (or better yet, post) the relevant log from /var/log/letsencrypt.
2 Likes
I respect that you choose to hide public ip address and public hostname.
IMVHO the chance that for one reason or another LE infrastructure do not solve correctly your public hostname (which should be the “primary” hostname of NethServer) to your public ip address a possible issue.
May I assume that you triple checked between the public IP and the A record on your public DNS?
May I assume that you also verified one way or another that this works also from outside your network and into different ISPs (TOR browser might a way)
May I assume that also you forwarded…
Public port 80 to NethServer RED (if present) port 80
Public port 443 to NethServer RED (if present) port 443
?
(for serveral reason, forwarding 80 to 443 is a bad idea)
May I assume that your ISP allows you to use/access/forward port 80?
Final question: are you using one way or another apache server port 80 for publishing websites?
404 in HTTP code errors means “not found”.
So, assuming that NethServer works (and I am aware it works perfectly, because of the 20 servers with certificate I installed, 10 since 36 months)… maybe the issue is not nethserver
Is there a reason you can’t copy/paste text, rather than posting an image? In any event, I don’t see a “connection refused” error there; I see a 404. Different problem entirely.
Edit: and what do you mean by this:
What router, and how is it involved?
I don’t. It makes it nearly impossible to troubleshoot these problems.
1 Like
This would be NS.
Yes.
Yes, the FQDN redirects from a VPN.
Yes.
It has worked in the past, and it seems to still work now, at least to 443.
Not on NS. Internally on the network, but on a different host. and the only port forward for port 80 is to NS.
I’m assuming it’s a setting I’m missing, and I need to figure out if there’s another log to investigate.
What exactly do you mean here?
Hi
Maybe because Port 80 on NS is forwarded to another internal server, so LE can’t verify…
My 2 cents
Andy
When I access the domain at port 80 (http) from a VPN (not my internal network), it connects, but forwards to port 443 (https).
This was my thought, so I deleted all configs and started over on NS. I shut down the server. Still no luck.
Maybe at this point I’ll start a fresh install of NS and see if that fixes it.
Might as well–you really aren’t giving us much to work with, and if you won’t share the domain name there’s nothing we can do but guess.
Thanks, Dan. You’ve been super helpful.
It won’t. Because…
this is the issue.
As dan pointed out, without information about public IP and hostname, community is not able to check/verify/validate (and exclude or point out if it’s everything ok) on it’s own what you provide as information.
In this case, i can only “imagine” and explain a scenario, hoping that this “paint” will help you to understand what’s going wrong on your setup.
Let’s say that you have two hosts. One is NethServer (dude.domain.tld), one is your webserver (www.domain.tld).
So.
dude.domain.tld
- must have a not-shared IP Address (
a.b.c.d) - must have a proper A record on public DNS
- must be reachable on port 80 and 443 on the ip address
a.b.c.d
and
dude.domain.tld
- must have a different not-shared IP Address (
e.f.g.h) - must have a proper A record on public DNS
- must be reachable on port 80 and 443 on the ip address
e.f.g.h
Otherwise somethings won’t work properly.
There’s a workaround, called virtualhost. Which I don’t now how to implement (for sure and without a doubt) but will work something like this…
dude.domain.tldandwww.domain.tldwill share the same public ip address (a.b.c.d)- the piece of software at
a.b.c.dis aware of that and can “route” (so improper way to call it, but it’s 3:30 am in the morning and i am no english mother language, be kind) the requests for port 80 and port 443 to the proper direction fordude.domain.tldandwww.domain.tld, which may be not the same system or webserver or even application. NethServer does something similar for Mattermost and at least one more module - otherwise, instead of virtualhost, a reverse proxy could achieve the same things, with different costrains
Consider that I am not capable currently (and maybe even after a proper night of sleep) design and implement such arrangement. Maybe someone can, but it’s still quite “job”, rather than “community support”.
Neverthless… This is the only thing that i can say “you did wrong” due to information you provide to the community. Dan might not share my “respect” for your choices, neverthless is totally right about the “limits” you are providing to the community to help you.
This my last post on this topic. I’m expecting to read a “solution story” by you, @anon23411752.
No, I don’t want to expose my private information online. I think this is reasonable. I am on here asking for clues to diagnose, not for someone to solve my problem. So for mods/devs to get b*tchy is a little ridiculous to me. Simply do not post, or say that you don’t have enough information to diagnose.
Honesty, I think NS is great, and it’s one of the few servers I’ve found for my use case (virtualized in proxmox) that just worked without driver issues. So I’m not surprised that mods/devs can be prickly, but it is something that will drive users away from a great product.
As you pointed out later, this isn’t correct, as you can define the FQDN with vhosts (which works for me). But in my case, I’ve deleted all other FQDN’s and vhosts, and only have one pointed directly at NS with both ports open.
Ok, gonna lie a bit about preceiding post.
I can relate and understand why. On the other side, as person which gave public access to email and application server, my personal opinion is that sometimes you have to trade off a bit of the obscurity.
I mean…
- your ISP knows the hostname due to the reverse pointer
- your DNS service know the static IP due to A record.
- let’sencrypt infrastructure knows both data and give you the certificate
And most of times… the public IP address is “owned” by ISP, not you. Anyway still your call share or not.
And…
Still something is not configured as expected and a viable way. Unfortunately on vHost I quite do not have any meaningful experience, and without more data I cannot pinpoint anything obvious.
I suggest you to look for vHost into the community, maybe some case fitting yours could help. FDQNs more or less are not relevant.
Last question: the hostname you’re requesting certificate for is the one only hostname that NethServer is impersoning?
Did you create a virtualhost in server manager with same FQDN as the Nethserver? I think this could be an issue.
You could test disabling (no need to delete) all virtualhosts in the server manager web server page except of the default one and check if you can get the LE certificate.
Let’s also check your installed software, maybe something is blocking the request:
rpm -qa nethserver-\* | sort