| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
|
| 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/ |
|
#2
|
| 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 |
|
#3
|
| In <4896ffb6$0$11868$3b214f66@usenet.univie.ac.at> Martin Paul |
|
#4
|
| 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/ |
|
#5
|
| 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 |
|
#6
|
| On 2008-08-04 15:01:20 +0100, Gary Mills > In <4896ffb6$0$11868$3b214f66@usenet.univie.ac.at> Martin Paul > 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 |
|
#7
|
| In article <48971609@212.67.96.135>, Dave .... > >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 |
![]() |
| Thread Tools | |
| Display Modes | |