Solaris 10 comes with a wget binary which is linked against OpenSSL, 
which is great. Unfortunately it doesn't know about any of the common 
public root CA certificates (like e.g. firefox).

When using wget to access e.g. SunSolve, like in:

   wget https://sunsolve.sun.com/patchdiag.xref

it fails with "self signed certificate in certificate chain" error. Many 
Linux distributions come with a default set of certificates in /etc. If 
you copy such a ca-bundle.crt to /etc/sfw/openssl/cert.pem things like 
the above wget command suddenly start to work fine.

While the administrator can install cert.pem as part of the post-install 
configuration, it would be much better if Sun included a default set of 
certificates with the OS. With either installation DVDs or checksum of 
downloaded ISO images for the OS the verification of the certificates 
would be done automatically, and "wget https://.../" would work 
out-of-the-box.

Opinions, anyone?

mp.
-- 
SysAdmin | Institute of Scientific Computing, University of Vienna
      PCA | Analyze, download and install patches for Solaris
          | http://www.par.univie.ac.at/solaris/pca/

Martin Paul wrote:
> Solaris 10 comes with a wget binary which is linked against OpenSSL, 
> which is great. Unfortunately it doesn't know about any of the common 
> public root CA certificates (like e.g. firefox).
> 
> When using wget to access e.g. SunSolve, like in:
> 
>   wget https://sunsolve.sun.com/patchdiag.xref
> 
> it fails with "self signed certificate in certificate chain" error. Many 
> Linux distributions come with a default set of certificates in /etc. If 
> you copy such a ca-bundle.crt to /etc/sfw/openssl/cert.pem things like 
> the above wget command suddenly start to work fine.
> 
> While the administrator can install cert.pem as part of the post-install 
> configuration, it would be much better if Sun included a default set of 
> certificates with the OS. With either installation DVDs or checksum of 
> downloaded ISO images for the OS the verification of the certificates 
> would be done automatically, and "wget https://.../" would work 
> out-of-the-box.
> 
> Opinions, anyone?
> 
> mp.


I use 'PCA' which calls wget, and that manages to download 
patchdiag.xref ok. However, I think the username and password are 
probably passed on the command line, so not exactly the most secure 
system - but perhaps better than the UK government's IT security!

dave

In <4896ffb6$0$11868$3b214f66@usenet.univie.ac.at> Martin Paul <map@par.univie.ac.at> writes:

>Solaris 10 comes with a wget binary which is linked against OpenSSL, 
>which is great. Unfortunately it doesn't know about any of the common 
>public root CA certificates (like e.g. firefox).

I submitted a bug report on this problem.  It's CR 6661895 with the
title `/etc/sfw/openssl/certs has no well known CA certificates'.
It affects a number of different products.  I don't know when it
will be fixed or become a patch.

For the time being, I extract the certificates from
/usr/java/jre/lib/security/cacerts to build a package that installs
them into /etc/sfw/openssl/certs .  They need hash symlinks as well.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

Dave wrote:
> I use 'PCA' which calls wget, and that manages to download 
> patchdiag.xref ok. However, I think the username and password are 
> probably passed on the command line, so not exactly the most secure 
> system - but perhaps better than the UK government's IT security!

I still haven't found a way to make the user/passwd not show up in the 
process list with wget for pca, but to no avail. I once tried a pretty 
nifty solution using wget -i, a temp file and user/passwd encoded into 
the URL, but this is non-standard and didn't work with some proxies.

Unfortunately wget doesn't support feeding authentication data via 
environment variables either. Using a temporary .wgetrc doesn't work as 
wget reads only one config file (it would then ignore ~/.wgetrc). I'm 
open for any ideas :)

Martin.
-- 
SysAdmin | Institute of Scientific Computing, University of Vienna
      PCA | Analyze, download and install patches for Solaris
          | http://www.par.univie.ac.at/solaris/pca/

Martin Paul wrote:
> Dave wrote:
>> I use 'PCA' which calls wget, and that manages to download 
>> patchdiag.xref ok. However, I think the username and password are 
>> probably passed on the command line, so not exactly the most secure 
>> system - but perhaps better than the UK government's IT security!
> 
> I still haven't found a way to make the user/passwd not show up in the 
> process list with wget for pca, but to no avail. I once tried a pretty 
> nifty solution using wget -i, a temp file and user/passwd encoded into 
> the URL, but this is non-standard and didn't work with some proxies.
> 
> Unfortunately wget doesn't support feeding authentication data via 
> environment variables either. Using a temporary .wgetrc doesn't work as 
> wget reads only one config file (it would then ignore ~/.wgetrc). I'm 
> open for any ideas :)
> 
> Martin.

Not perfect, but you could hard-code the username and password into 
wget. It's open source, so can't be hard to hack to do that.

You might need to watch if 'strings' can be used on it, but again, it 
would not be hard ensure it could not be.

Personally, since the computer is in my own home, it's not an issue, so 
I don't care it is on the command line, but I realise it would be rather 
stupid in a multi-user environment.

But given anyone can register to download the patchdiag ref file, not 
requiring any payment, one could easily create an account with 
hotmail/gmail and don't worry too much about the security of it.

dave

On 2008-08-04 15:01:20 +0100, Gary Mills <mills@cc.umanitoba.ca> said:

> In <4896ffb6$0$11868$3b214f66@usenet.univie.ac.at> Martin Paul 
> <map@par.univie.ac.at> writes:
> 
>> Solaris 10 comes with a wget binary which is linked against OpenSSL,
>> which is great. Unfortunately it doesn't know about any of the common
>> public root CA certificates (like e.g. firefox).
> 
> I submitted a bug report on this problem.  It's CR 6661895 with the
> title `/etc/sfw/openssl/certs has no well known CA certificates'.
> It affects a number of different products.  I don't know when it
> will be fixed or become a patch.

The SFWopenssl package in OpenSolaris also does not include any CA certs.

Would Sun be somehow liable if an end-user trusted something nasty 
signed by one of these certificates?

> For the time being, I extract the certificates from
> /usr/java/jre/lib/security/cacerts to build a package that installs
> them into /etc/sfw/openssl/certs .  They need hash symlinks as well.

Cheers,

Chris

In article <48971609@212.67.96.135>, Dave  <foo@coo.com> wrote:
....
>
>Not perfect, but you could hard-code the username and password into 
>wget. It's open source, so can't be hard to hack to do that.
>
>You might need to watch if 'strings' can be used on it, but again, it 
>would not be hard ensure it could not be.

Not allow strings to be run on it?   How?

(or might you mean just protect it execute-only? -- or
something more complicated?)

Thanks,

David