Member Avatar for Mocabilly

Hi all,

First of all, I never experienced problems using secured pages, except for (this) one site.

To picture it in short, I use a login page, get directed to an other login page, I DO get logged in, and as I'm logged in, an other page (main secured page) is normally loaded.

Problem: using Firefox and Opera in Linux gives the following errors:

Firefox: (free translation) "Can't find the server on" followed by a string containing some numbers and letters, ends on a dash (hyphen?) a dot, followed by the domain name from the site.

Opera: "You tried to access the address " followed by an url starting with "https://" and containing a different address then firefox mentions.

I use Ubuntu, Xubuntu, Zenwalk and Slax, on different computers, and get the
same error on all of them :(

An other maybe interesting fact is that in the past I didn't have any problems at all logging in, but like half a year ago this error started, after trying a few times I could get logged in.
This could be (probably is) because the string mentioned above was changing every login, and is not changing anymore now...

To me it seems there are 2 possible sources for the error.
- Firefox and Opera can't handle certain character(combo's) in url's (the changing string part in the url)
- The folks running the website have some bugs in there scripts/server

In the end I can leave out the possible "network-error" or "firewall blocking" thing because I tried without firewall, and all other secured pages just work.

So my question (if you are still reading (I do hope so)) is:
Does anybody else have this problem?
Tips on solving this one? (I can't directly get to talk to the people running the site, the people from the help desk won't put me in contact with them)

  • 3 Contributors
  • 6 Replies
  • 308 Views
  • 2 Months Discussion Span
  • Latest Post Latest Post by Mocabilly

Dani AI

Generated

Short expert summary and practical next steps.

As later reported, the immediate symptom was a Linux-only name-resolution failure that went away after creating a local override; ’s Windows test and ’s request for a URL were on-point because the behaviour differed by OS (Windows worked; Linux did not). The most likely root causes are (a) the site issues per-login hostnames or redirects that produce non-standard labels, or (b) the Linux name-resolution stack rejects/does not see the generated hostname while Windows accepts it. DNS labels are expected to follow the LDH rules (letters, digits, hyphen; hyphen not allowed at the start or end of a label). (rfc-editor.org)

How to reproduce and diagnose (run these on the Linux box that shows the failure):

dig +short problematic-hostname.example
getent hosts problematic-hostname.example
curl -I -L -v 'https://initial-login-url.example'   # follow redirects, show Location headers
openssl s_client -connect ip:443 -servername problematic-hostname.example

Use dig/getent to confirm whether the name resolves at all, and curl -I -L -v (or wget --server-response) to capture the redirect chain and the exact hostnames the server returns. openssl s_client -servername tests the certificate/SNI the server will present. dig and curl are standard troubleshooting tools. (mankier.com)

Why the hosts-file workaround helped, and caveats: a local /etc/hosts entry forces the resolver to map that hostname to an IP (the hosts file format and behaviour are documented in hosts(5)); which explains why the browser can connect after the entry is added. The system uses the order in /etc/nsswitch.conf to decide whether files (/etc/hosts) or dns is consulted first, so check that if your entry doesn’t seem to take effect. (man7.org)

If fixing the site is an option, report the exact redirect hostnames (captured with the commands above) and ask the operators to avoid generating hostnames that violate hostname rules or to use path/cookie-based session tokens. If you must keep a local workaround, be aware it may break with server-side load balancing, IP changes or future maintenance; clear local resolver/browser caches after changes (resolvectl flush-caches / restart nscd/dnsmasq or restart the browser) to ensure fresh lookups. (manpages.debian.org)

Recommended Answers

All 6 Replies

Member Avatar for sillyboy

do firefox and opera in windows work?

Member Avatar for Mocabilly

do firefox and opera in windows work?

Well, I just tried, and it did work under windows...
(but I rarely can use a windows machine...)

Member Avatar for sknake

>>- The folks running the website have some bugs in there scripts/server

Sounds like an issue on their end. Unfortunately without being able to reproduce the problem its almost impossible to give you advice. Are you willing to share the URL?

Member Avatar for Mocabilly

>>- The folks running the website have some bugs in there scripts/server

Sounds like an issue on their end. Unfortunately without being able to reproduce the problem its almost impossible to give you advice. Are you willing to share the URL?

Well, It's not a public site so I can't (not allowed to) give you the URL :(

But if you too think there's a bug in the scripts/server, I feel feel more confident to put things further then our helpdesk, at which they also haven't got a clue, and can't even get in touch (told me) with the people doing the maintaining of the website...

I't isn't going to be a matter of days, before I expect to be able to contact one of those people...
Anyway, I'll keep you posted

Thnx for looking into my problem..
Hope to inform you soon on the outcome but as I said, that can take a while.. :(

grtz

Mocabilly

Member Avatar for Mocabilly

Well, I tried firefox for windows under wine, same error... :(

Member Avatar for Mocabilly

Hi all,

My problem (below) is solved..

It seems that "somehow" in linux that domain name isn't auto-resolved to the IP address.. (why, I still don't know)
I added an entry containing the domain with the special key added to it , to my /etc/hosts file, now everything just works fine..

Just as some extra info to you, en example of how to add a domain
to your /etc/hosts file, you have to add it in this way:


(IPaddress tab domainname)

Hi all,

First of all, I never experienced problems using secured pages, except for (this) one site.

To picture it in short, I use a login page, get directed to an other login page, I DO get logged in, and as I'm logged in, an other page (main secured page) is normally loaded.

Problem: using Firefox and Opera in Linux gives the following errors:

Firefox: (free translation) "Can't find the server on" followed by a string containing some numbers and letters, ends on a dash (hyphen?) a dot, followed by the domain name from the site.

Opera: "You tried to access the address " followed by an url starting with "https://" and containing a different address then firefox mentions.

I use Ubuntu, Xubuntu, Zenwalk and Slax, on different computers, and get the
same error on all of them :(

An other maybe interesting fact is that in the past I didn't have any problems at all logging in, but like half a year ago this error started, after trying a few times I could get logged in.
This could be (probably is) because the string mentioned above was changing every login, and is not changing anymore now...

To me it seems there are 2 possible sources for the error.
- Firefox and Opera can't handle certain character(combo's) in url's (the changing string part in the url)
- The folks running the website have some bugs in there scripts/server

In the end I can leave out the possible "network-error" or "firewall blocking" thing because I tried without firewall, and all other secured pages just work.

So my question (if you are still reading (I do hope so)) is:
Does anybody else have this problem?
Tips on solving this one? (I can't directly get to talk to the people running the site, the people from the help desk won't put me in contact with them)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.