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, 01:54:15 AM

Title: ca-certificates
Post by: hiro on August 27, 2015, 01: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:
Quote
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
Title: Re: ca-certificates
Post by: Jason W on August 27, 2015, 07:23:29 AM
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.
Title: Re: ca-certificates
Post by: hiro on August 27, 2015, 07:56:06 AM
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?
Title: Re: ca-certificates
Post by: Jason W on August 27, 2015, 09:01:21 AM
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. 
Title: Re: ca-certificates
Post by: Jason W on August 27, 2015, 10:42:45 AM
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
Title: Re: ca-certificates
Post by: hiro on August 27, 2015, 11:34:53 AM
Thanks. Will try tomorrow.
Title: Re: ca-certificates
Post by: Jason W on August 27, 2015, 03:43:08 PM
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/...   
Title: Re: ca-certificates
Post by: hiro on August 29, 2015, 03:46:10 AM
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?
Title: Re: ca-certificates
Post by: hiro on August 29, 2015, 05:53:23 AM
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)
Title: Re: ca-certificates
Post by: gordon64 on August 29, 2015, 06:00:35 AM
Hi

try these if interested bottom may be relevant to irssi?
untested in dcore but works in 32/64 TC
Code: [Select]
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

Title: Re: ca-certificates
Post by: Jason W on August 29, 2015, 06:01:11 AM
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.
Title: Re: ca-certificates
Post by: hiro on August 29, 2015, 01:44:46 PM
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.
Title: Re: ca-certificates
Post by: hiro on August 29, 2015, 02:01:38 PM
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.
Title: Re: ca-certificates
Post by: gordon64 on August 29, 2015, 06:25:21 PM
Quote
/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.

Code: [Select]
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


Title: Re: ca-certificates
Post by: hiro on August 30, 2015, 03:01:20 AM
Do you have any crt or pem files in /etc/ssl/certs?
of course, in the mozilla subfolder.

Quote
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?

Quote
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?
Title: Re: ca-certificates
Post by: Jason W on August 30, 2015, 04:11:47 AM
Ok, looking at my HD install I see what needs to be done.
Title: Re: ca-certificates
Post by: gordon64 on August 30, 2015, 04:51:43 AM
Hi
Quote
of course, in the mozilla subfolder.
then you have none in the parent directory /etc/ssl/certs?

Quote
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
Quote
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
Title: Re: ca-certificates
Post by: Jason W on August 30, 2015, 06:02:56 AM
Before spending any more time with what is the current ca-certificates package, I have a very simple solution.

Will upload shortly.
Title: Re: ca-certificates
Post by: Jason W on August 30, 2015, 07:03:23 AM
ca-certificates package has been update, please re-import and test.
Title: Re: ca-certificates
Post by: hiro on August 30, 2015, 09:23:16 AM
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.
Title: Re: ca-certificates
Post by: Jason W on August 30, 2015, 10:32:49 AM
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.
Title: Re: ca-certificates
Post by: Jason W on August 30, 2015, 11:17:11 AM
Fix uploaded.  I am away from my own machine and can't test but it should be good now.
Title: Re: ca-certificates
Post by: hiro on August 30, 2015, 12:10:53 PM
Yep, it works fine now, thanks.
Title: Re: ca-certificates
Post by: Jason W on August 31, 2015, 05:04:44 AM
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.