root CA certificates for wget/openssl
Martin Paul
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/
Dave
> 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
Gary Mills
>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-
Martin Paul
> 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.
Dave
> 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
Chris Ridd
> In <4896ffb6$0$11868$3b21...@usenet.univie.ac.at> Martin Paul
> <m...@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
David Combs
...
>
>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