Links browser with secure connections: is this error normal?
 

Recently I have:

- compiled OpenSSL 1.1.0f and installed it in a user folder;

- compiled Links 2.14 with SSL support and also installed in a user folder.

Detailed comments about these two steps are given in another thread: "How to use OpenSSL installed in a different dir to compile Links?", which still has a question about SSL v2 and v3.

After compiling Links, the first page I visited was hotmail.com, which is redirected to another domain in a secure connection. But Links asked me:

==
Invalid certificate
The server mail.live.com doesn't have a valid certificate.
Do you want to connect to it anyway?
[No] [Yes]
==

After sometime, I tried other secure pages that work normally in other browsers. They also do not work with my Links:

duckduckgo.com
mail.yahoo.com
https://LQ.org/questions/login.php

For all of them, Links said their certificate is invalid, same question.

Is this normal? Is it because I compiled from source? Is it because SSL v2 and v3 are not working, as I showed/asked in the other thread?

I just went to https://duckduckgo.com and https://LQ.org/questions/login.php in links with no errors. This was the default links that comes with Slackware.

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.

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.


Yes how and where you installed software and dependencies matters yuugely, because from reading this:


...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.)

That may be possible. Although it is not the most common scenario, it is not something that should fail.

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.

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?

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.

YMMVM? What is that? I could only find YMMV: onlineslangdictionary.com/meaning-definition-of/ymmv (says it is "your mileage may vary").

If you do things "By the Book", that is install pre-packaged software, this error would not occur.


No, that's correct.


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;'.)


You must not use SSLv2 or SSLv3 as they're whorribly insecure, ancient, blisteringly outdated, deprecated, you get it.


Shame you didn't elaborate why not.


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.


Yes, that should read YMMV(VM) as in "Your Mileage May Vary (Very Much)" ;-p