<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thorsten and the group,<br>
Fair enough. What I am trying to do in this particular case is
use Openssl v1.1 to support building an application, and see if
existing apps could use it. The answer to the latter is typically
no, of course, as they are built against v1.0.2, which is a
situation similar to using the Security Channel of previous
versions of SLES to supply a few key apps built with another
version of SSL. Building my own code needs SSL v1.1 for checking
matters, and that means both the library and the headers (-devel
bundle). <br>
Where matters become sticky is adding the -devel material, where
YaST decides that we must remove all of the earlier SSL material
(thus the earlier library as well). I think that is a step too far
in the dependency resolution problem, where there is conflict only
about the -devel part. This seems to be readily curable by a
script tweak or two.<br>
So far, the running of apps is indeed supported by symlink
libssl.so and we can install multiple libssl's. I point the
symlink at an active library. Building an application with other
than the stock SSL runs into difficulties because adding a more
recent SSL -devel part causes wider spread trouble. <br>
<br>
Next there are the certificates. Right now this seems to be a
muddle. I have two Beta 3 machines set up, one with the choice of
SSL v1.1 and the second with the stock SSL v1.0.x. The first has
experienced the discussed problems, and the second does work
reasonably well. The certificate blockage does seem to be a
dependency criteria which I have not decoded. <br>
Here is a screen capture of one case: on the SSL v1.1 (first)
machine. In YaST ask to install the ca-certificates RPM material,
and the conflict resolution screen shown below appears:<br>
<img src="cid:part1.37487E2A.C7FD459F@netlab1.net" alt=""
height="482" width="646"><br>
It says that to obtain the CA cert material I also must remove
SSL v1.1, for unknown reasons. The best that I can guess is there
is some hidden agent which is built against SSL v1.0.x which wants
to be a guardian of such certs and can't work with SSL v1.1. Just
where I would place my regular cert material is uncertain as there
is no corresponding area in either /etc/ssl nor /var/lib. Note
that for this report's tests I have pointed the libssl.so symlink
at the SSL v1.0.x library, thusly:<br>
<img src="cid:part2.39DD2747.7EFD91FD@netlab1.net" alt=""
height="108" width="539"><br>
Note the date stamp on that symlink as it shows I modified it
yesterday for this test. <br>
<br>
Next, the software update error messages on the SSL v1.1
machine. Four screen captures. <br>
The first is visiting YaST Online Update:<br>
<img src="cid:part3.CA4829FA.EF8591D1@netlab1.net" alt=""
height="499" width="678"><br>
<br>
Skipping the Autorefresh produces this curl error 60 popup:<br>
<img src="cid:part4.F2468E5F.D91DBAE8@netlab1.net" alt=""><br>
<br>
Then if one issues command zypper lu the screen shows many
lines such as this one:<br>
<img src="cid:part5.677C5016.6A0DAA34@netlab1.net" alt=""
height="91" width="628"><br>
<br>
or the same but in a terminal session in the GUI:<br>
<img src="cid:part6.63332D9D.12028D4C@netlab1.net" alt=""
height="95" width="636"><br>
<br>
All are saying the CA cert is not available, which we know from
the CA problem above, and indeed there is no CA cert area.<br>
<br>
From my vantage a couple of comments.<br>
First, have the usual CA bundle be present/installable,
regardless of OpenSSL versions. That takes some detective work at
the SUSE end to resolve. Then Curl, Apache, zypper et al would
stand a chance of running against at minimum a self signed cert or
more normally against a user supplied set. Swapping a symlink for
development is the manager's choice.<br>
Second, the /etc/ssl grouping of cert material makes good
sense. This goes against the unfortunate LSB grain of scattering
things all over. The reason is to get at the certificate material
(as we must these days) in a simple easy to remember fashion and
avoid being tripped up by symlinks hiding elsewhere. It's usage in
the field which is important, a people and management time
concern.<br>
Thanks,<br>
Joe D.<br>
<br>
<br>
On 29/11/2017 21:01, Thorsten Kukuk wrote:<br>
</div>
<blockquote type="cite" cite="mid:20171129210106.GA4741@suse.de">
<pre wrap="">On Wed, Nov 29, Joe Doupnik wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> In my view, the /etc/ssl construction prior to SLES15 is superior,
clear, manageable, and what we have wired into our applications.
</pre>
</blockquote>
<pre wrap="">
How can the /etc/ssl construct prior to SLES15 be superior if it is
identical between SLES12 and SLES15?
Maybe you should start at first in your bug reports with what you are
exactly doing and what the exact error messages are? Beside that it is
not working on one machine for you, there is not much we can use to
identify the root cause.
Start for example with the error message of update-ca-certifiates.
Beside that, if changing the libssl.so symlink makes a different for you,
that you have some broken third party RPMs flying around somewhere.
libssl.so is only used for linking applications, it should never be
needed at runtime. If you have applications which needs this link at
runtime, you have lost. This will never work stable.
And libssl.so is coming with a *-devel RPM. And the *.so symlink has
to match exactly the header files, else compiling and linking will
never work, too. If you have the wrong *-devel package installed,
you should deinstall it and install the right one, not changing
symlinks.
Thorsten
</pre>
</blockquote>
<br>
</body>
</html>