Bug#790943: server certificates/key pairs and CA directories
On 21/07/15 18:50, Thorsten Glaser wrote: Daniel Pocock daniel at pocock.pro writes: I looked at the package ssl-cert to try and understand and there I found that it is using /etc/ssl/certs for server certs while other packages Do NOT do that. I wasn't suggesting that was desirable, it is just what I observed. As mentioned, I had actually reported a but about it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790943 I agree that applications should check the CA constraint, but I feel it increases the risk of administrative and programming errors when everything is in a single directory. It’s causing trouble because some software (e.g. Gajim) reads all files under /etc/ssl/certs/ not just the hashed ones – presumably because OpenSSL 1.x changed the algorithm used for the hash, while GnuTLS keeps using the OpenSSL 0.x one (in MirBSD I just symlink them both). My suggestion is: /etc/ssl/private/foo.key ← 0640 root:ssl-cert, secret key /etc/ssl/foo.cer ← 0644 root:ssl-cert, public key / certificate plus DH parameters /etc/ssl/foo.ca ← 0644 root:ssl-cert, certificate chain EXCLUDING root certificate Then make sure to use the same “foo”. Looking through various Debian boxes, I can't help noticing a range of directories under /etc/ssl, e.g. # ls -l /etc/ssl total 60 drwxr-xr-x 2 root root 20480 Jun 6 18:57 certs -rw-r--r-- 1 root root 10835 Mar 18 2013 openssl.cnf drwx--x--- 2 root ssl-cert 4096 Jan 21 2014 private drwxr-xr-x 2 root root 4096 Oct 20 2007 ssl.crl drwxr-xr-x 2 root root 4096 Jul 1 18:49 ssl.crt drwxr-xr-x 2 root root 4096 Jan 21 2014 ssl.csr drwxr-xr-x 2 root root 4096 Jun 4 13:35 ssl.key drwxr-xr-x 2 root root 4096 Oct 20 2007 ssl.prm and on a more recent box: # ls -l /etc/ssl total 44 drwxr-xr-x 2 root root 24576 Jan 28 2015 certs -rw-r--r-- 1 root root 10835 Jun 15 2014 openssl.cnf drwx--x--- 2 root ssl-cert 4096 Jul 21 2014 private Does anybody know which packages create or use the /etc/ssl/ssl.* directories and was there any standard for using them? The default permissions on /etc/ssl/ssl.key don't look great -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55bdd9d2.3010...@pocock.pro
Bug#790943: server certificates/key pairs and CA directories
On Sun, Aug 2, 2015 at 4:50 PM, Daniel Pocock wrote: Does anybody know which packages create or use the /etc/ssl/ssl.* That looks like a sysadmin created path, only one package even mentions it: https://codesearch.debian.net/search?q=/etc/ssl/ssl -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HPc+DXRciJesw9cPSCptVbMQT=P_8czF7UK=gxfnf...@mail.gmail.com
Bug#790943: server certificates/key pairs and CA directories
On 2 August 2015 11:25:35 CEST, Paul Wise p...@debian.org wrote: On Sun, Aug 2, 2015 at 4:50 PM, Daniel Pocock wrote: Does anybody know which packages create or use the /etc/ssl/ssl.* That looks like a sysadmin created path, only one package even mentions it: https://codesearch.debian.net/search?q=/etc/ssl/ssl I suspected from the timestamps that these paths may have been created or referred to by an older version of some package, codesearch only checks sid -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/79060588-0a50-4e2b-93cd-a5d7db3f1...@pocock.pro
Bug#790943: server certificates/key pairs and CA directories
Daniel Pocock writes: Looking through various Debian boxes, I can't help noticing a range of directories under /etc/ssl, e.g. I have no idea if this has been discussed before but what it comes to private key storage, there is program named tpmtool (part of GnuTLS) that allows storing private keys in place out-of-the-filesystem. I have not tried using it myself so I don't know if there is useful API available or anything - just the idea seems good to me - so maybe advocating usage of that method might be the Correct Way? Also fallback option should be in place for HW where TPM chip is not present.. -- Antti Järvinen -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21950.38591.288120.975...@muikku.katiska.org
