Links browser with secure connections: is this error normal?
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Thank you for the test, frankbell. I suppose that hotmail.com would also load with no error for you. I cannot understand why the certificates are considered invalid in my computer.
Links is not installed in a machine I use. And I have no root access to it. I compiled and installed Links there just for me. And, before that, compiling and installing OpenSSL was needed.
What distro is on the machine you were using links on?
Does it matter? I compiled both Links and OpenSSL from source, current versions.
There are several machines I can run the Links I built. They are Ubuntu 14.04.5 LTS and 16.04.2 LTS. Right now, I have tested in both kinds of machines, the behaviour is exactly the same.
I cannot understand why the certificates are considered invalid in my computer.
Officially-issued SSL certificates are not autonomous but are chained all the way up to the Certificate Authority (CA) that issued them. That's also why you get errors with self-signed certs as there is no CA to validate them. My first hunch would be it's not finding root certs to work with.
Quote:
Originally Posted by dedec0
Does it matter? I compiled both Links ann OpenSSL from source, current versions.
Yes how and where you installed software and dependencies matters yuugely, because from reading this:
Quote:
Originally Posted by dedec0
Links is not installed in a machine I use. And I have no root access to it. I compiled and installed Links there just for me. And, before that, compiling and installing OpenSSL was needed.
...we can understand the SSL warning may not be caused by some common error but brought on by doing things in a non-standard way. (And probably SSL libraries were installed but not the development libraries needed for compiling software.) The first best way to fix things good would be to undo whatever it is you did and ask the admin to install (e)links properly for you. And IMHO there should be no valid reason not to do so.
*Should you want to pursue the alternative anyway (YMMVM) then first run some diags: see if you can spot a difference when doing 'true | /path/to/your/custom/openssl s_client -connect mail.live.com:443;' vs 'true | /usr/bin/openssl s_client -connect mail.live.com:443;'. If there is then ensure your (SSL) development libraries match the versions on each system and ensure the compile time configuration for finding /etc/pki (or wherever SSL asserts its certificate structure is located at) matches each system. (There's prolly SSL-related configuration files or environment variables to do so but that may or may not work and will most likely bite you when you decide more applications dependant on SSL.)
...we can understand the SSL warning may not be caused by some common error but brought on by doing things in a non-standard way.
That may be possible. Although it is not the most common scenario, it is not something that should fail.
Quote:
(And probably SSL libraries were installed but not the development libraries needed for compiling software.)
This is possibly true. But I imagine that if some development library was missing for OpenSSL or for Links, their configure script should have warned me - is this idea wrong? If some certificate is also needed (not just the OpenSSL dev. lib.), it should be pointed with a different option - right?
As said in the first post of this thread, and in the other thread about OpenSSL+Links in different dirs, Links' configure script said that SSL v2 and V3 were not enabled. Until now, no-one commented that detail in both threads. I would choose to enable them, but I have not seen the reason for them being disabled. There is no option specifically to SSL v2 or v3 in Links' configure script.
Quote:
The first best way to fix things good would be to undo whatever it is you did and ask the admin to install (e)links properly for you. And IMHO there should be no valid reason not to do so.
This is not an option, for reasons not chosen by me. And I want to be able to fully build and install Links - why not?
Quote:
*Should you want to pursue the alternative anyway (YMMVM) then first run some diags: see if you can spot a difference when doing 'true | /path/to/your/custom/openssl s_client -connect mail.live.com:443;' vs 'true | /usr/bin/openssl s_client -connect mail.live.com:443;'. If there is then ensure your (SSL) development libraries match the versions on each system and ensure the compile time configuration for finding /etc/pki (or wherever SSL asserts its certificate structure is located at) matches each system. (There's prolly SSL-related configuration files or environment variables to do so but that may or may not work and will most likely bite you when you decide more applications dependant on SSL.)
Is the output of these two commands safe to be pasted here? I ran both, and they are different. I would like to show to you, but tell me if I should edit something in these lines' outputs before copying them here.
That may be possible. Although it is not the most common scenario, it is not something that should fail.
If you do things "By the Book", that is install pre-packaged software, this error would not occur.
Quote:
Originally Posted by dedec0
This is possibly true. But I imagine that if some development library was missing for OpenSSL or for Links, their configure script should have warned me - is this idea wrong?
No, that's correct.
Quote:
Originally Posted by dedec0
If some certificate is also needed (not just the OpenSSL dev. lib.), it should be pointed with a different option - right?
Yes, with "--openssldir". However: if unset it'll default to "/usr/local/ssl". (See for yourself with '/path/to/your/custom/openssl version -d;' versus '/usr/bin/openssl version -d;'.)
Quote:
Originally Posted by dedec0
As said in the first post of this thread, and in the other thread about OpenSSL+Links in different dirs, Links' configure script said that SSL v2 and V3 were not enabled. Until now, no-one commented that detail in both threads. I would choose to enable them, but I have not seen the reason for them being disabled. There is no option specifically to SSL v2 or v3 in Links' configure script.
You must not use SSLv2 or SSLv3 as they're whorribly insecure, ancient, blisteringly outdated, deprecated, you get it.
Quote:
Originally Posted by dedec0
This is not an option, for reasons not chosen by me. And I want to be able to fully build and install Links - why not?
Shame you didn't elaborate why not.
Quote:
Originally Posted by dedec0
Is the output of these two commands safe to be pasted here? I ran both, and they are different. I would like to show to you, but tell me if I should edit something in these lines' outputs before copying them here.
Basically what you'll be posting is diagnostic output of openssl interpreting how it should validate encountered remote certs. So as long as those certs are publicly accessible and the FQDN is not (in)directly linked to anything you would not want to associate yourself with publicly then there's no harm in sharing that nfo.
Quote:
Originally Posted by dedec0
YMMVM? What is that? I could only find YMMV: onlineslangdictionary.com/meaning-definition-of/ymmv
Yes, that should read YMMV(VM) as in "Your Mileage May Vary (Very Much)" ;-p
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.