Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => dCore x86 Imported Extensions => Topic started by: hiro on August 27, 2015, 04:54:15 AM
-
anyone using them? here it doesn't get properly initialized post install.
when i run the tce.installed script manually i get this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
-
What is not working with the installed certificates?
And I don't see that debconf warning. I only see the LANG not being set therefore falling back to C, and that would go away by setting LANG.
-
I would have expected certs to appear in /etc/ssl, that doesn't happen.
Perhaps a better question would be: where does the openssl default CA path get saved?
-
Ok, here is where we have to use a script to simply copy the certs from where Debian stages them to the /etc/ssl directory. I will create a startup script to do this.
-
Ok, update or re-import whatever SCE contains the ca-certificates package and reboot and reload.
Should have the certs in the /etc/ssl/certs directory. And the /usr/local/tce.installed/ca-certificates script can be re-run by other packages' startup scripts as a trigger if any new certs are placed in /usr/share/ca-certificates
-
Thanks. Will try tomorrow.
-
igtf-policy-classic is the only other Debian package that uses /usr/share/ca-certificates for ready to use certificates, it's startup script now calls on the ca-certificates script to include it's contents in /etc/ssl/...
-
So now with the updated openssl.tcz in 6.x more things appear to me:
openssl.tcz always shipped with cacert.crt, generated from http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cacerts.html.
openssl sce only comes with the mozilla and spi certs, which newest openssl.tcz also includes in addition to the lfs cacert.
I actually have no idea why there are 3 different sources for our certificates: mozilla, lfs and spi.
And I also don't know how programs choose one folder over the other.
Right now I have irssi hardcoded to the cacert file from lfs, which works in 6.x but not in dcore.
Perhaps I should change my hardcoded paths, but as this is important enough I spout it out here for discussion.
Is there a document describing best practices for ca certificates?
-
A good test is this:
strace openssl s_client -CApath /etc/ssl/certs/ -connect google.com:443 2>&1 |grep 'ENOENT'
it fails while trying to read these two certs, that don't exist with dcore's ca-certificates package:
stat64("/etc/ssl/certs//578d5c04.0", 0xbfd55cf0) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/ssl/certs/578d5c04.0", 0xbfd55cf0) = -1 ENOENT (No such file or directory)
-
Hi
try these if interested bottom may be relevant to irssi?
untested in dcore but works in 32/64 TC
openssl s_client -connect www.paypal.com:443
openssl s_client -connect www.freenode.net:443
the Common Name (CN) you may be looking for is GlobalSign Organization Validation CA - G2
good luck
-
Below is where LFS gets it's certs, it is listed on it's ca-certificates package page:
https://hg.mozilla.org/releases/mozilla-release/file/default/security/nss/lib/ckfw/builtins/certdata.txt
It is one file, whereas Debian Breaks the entries up into a file a piece. And it is also from Mozilla.
ca-certificates.tcz contains the same entries as the Debian package does, but also with some legacy .pem symlinks. So it is the same certs.
If irssi was built on Core and things are hardcoded to /usr/local, then it will not work on other systems. Prebuilt packages for dCore are built on dCore.
-
With "hardcoded" in irssi I mean I specified the CA path in the config file. On 6.x specifying /etc/ssl/certs works.
The irssi used on dcore is the one from debian. There specifying /etc/ssl/certs with only the mozilla folder beneath doesn't succeed.
It doesn't really matter what I do in irssi though, cause even with plain openssl I get the same result. It might be that the above example needs -CApath /etc/ssl/ appended to the openssl command. Without it also doesn't succeed on tc 6.0.
-
The only thing to get anything working on dcore for me is to do
sudo c_rehash /etc/ssl/certs/mozilla/
and then specify capath to mozilla dir, e.g.
strace openssl s_client -connect google.com:443 -CApath /etc/ssl/certs/mozilla/
same in irssi, with capath specified as /etc/ssl/certs/mozilla/ it works now, but it required the rehash first.
-
/etc/ssl/certs/mozilla/
Do you have any crt or pem files in /etc/ssl/certs?
Most web browsers and some apps look in that folder.
Leaping ahead, without knowing your answer etc
you could try this assuming individual crt files in mozilla
The reason for the move bundle command is c_rehash only looks at the first certificate in the bundle in hashing it, giving you a duplicate error we don't need. Delete that line if you have no bundle. But if possible pls advise if you have no bundle.
sudo su
mv /etc/ssl/certs/mozilla/ca-certificates.crt /etc
ln -s /etc/ssl/certs/mozilla/* /etc/ssl/certs/
cd /etc/ssl
c_rehash
mv /etc/ca-certificates.crt /etc/ssl/certs/
good luck
-
Do you have any crt or pem files in /etc/ssl/certs?
of course, in the mozilla subfolder.
Most web browsers and some apps look in that folder.
How did you find out? Do you have a list, an overview over these browsers and apps?
Leaping ahead, without knowing your answer etc
you could try this assuming individual crt files in mozilla
The reason for the move bundle command is c_rehash only looks at the first certificate in the bundle in hashing it, giving you a duplicate error we don't need. Delete that line if you have no bundle. But if possible pls advise if you have no bundle.
I don't know what you are suggesting here. What is a move bundle command? I didn't get any duplicate error? What do you mean?
btw, here is the current dcore deb2sce script: http://tinycorelinux.net/dCore/import/ca-certificates.deb2sce
and here the tc 6 extension: http://tinycorelinux.net/6.x/x86/tcz/openssl.tcz
Be aware there's also a postinst script in the deb which I tried to read but can't understand the purpose of.
And are we even running the postinst script?
-
Ok, looking at my HD install I see what needs to be done.
-
Hi
of course, in the mozilla subfolder.
then you have none in the parent directory /etc/ssl/certs?
Do you have a list, an overview over these browsers and apps?
My bad, I mean, for those browsers that do not use their own certificates, and support https
----they tend to look in /etc/ssl
firefox and opera(-12) ON 32/64 bit use their own certs.
AFAIK, if built that way elinks, lynx use openssl certs.
fifth handles certificates differently, invented by Curaga and shows here
http://fifth-browser.sourceforge.net/features.html
CAs are ignored, the only thing that matters is that the cert does not change
2) ca-certificates.crt is a bundle of certificates, hence I called it a bundle....sorry for not explaining
3) I don't and have never used dcore but looking at your link on the script, I am sure the maintainer can explain it better than I can. but I will give it a go
################
if the directory /etc/ssl/certs does not exist then create it.
next because the script is already in the directory /usr/share/ca-certificates
copy those files to /etc/ssl/certs/
##################
4) Can you see that its the contents of the top level of /etc/ssl/certs/ that is important. Its OK to have a sub-folder as long as certificates exist in the certs directory (folder)
good luck
-
Before spending any more time with what is the current ca-certificates package, I have a very simple solution.
Will upload shortly.
-
ca-certificates package has been update, please re-import and test.
-
your line
find `ls` -not -type -d > /etc/ca-certificates.conf
doesn't work:
find: Arguments to -type should contain only one letter
After fixing that locally the script now triggers the rehash thing and everything works well:
$ openssl s_client -connect google.com:443 -CApath /etc/ssl/certs
...
Verify return code: 0 (ok)
Perhaps you should also use >> in case someone adds his own personal cert dirs before loading ca-certificates.
-
Type, -d should be d, will fix it.
And I will >> the instead of >, as that script is only run once and then is used by one more package I believe.
-
Fix uploaded. I am away from my own machine and can't test but it should be good now.
-
Yep, it works fine now, thanks.
-
Good news.
For a more correct function, I will make it where when the startup script is run then only entries that are not already in /etc/ca-certificates.conf will be added so the file does not grow with duplicate entries each time the script is run.