I've marked this bug serious because it could lead to security problems if people mix root certs and other certs in the same directory This package provides the script /usr/sbin/make-ssl-cert It creates certificates and puts the public key / certificate PEM file in /etc/ssl/certs The ca-certificates package puts symlinks to CA certificates in the same location, /etc/ssl/certs Some other packages refer to /etc/ssl/certs as a directory of trusted roots. E.g. according to this page: https://wiki.debian.org/ServicesSSL the whole directory was trusted by wget in wheezy but not in jessie. Some people suggest using /etc/ssl/ssl.crt or /etc/ssl/public for local certificate files. I did a Google search to try and find out of there is a policy about this directory and no results were found. So I can't say that this package is violating any specific policy or what should be done to fix it, but I do feel the status quo is troublesome. Should local certs go in some other directory, or should other packages stop trusting everything in /etc/ssl/certs? If it is the latter, then maybe some QA check is needed to evaluate how many packages refer to that location. I came across these pages relating to the topic: https://wiki.debian.org/Cryptography https://wiki.debian.org/X.509 https://wiki.debian.org/SslCertificateHandling https://wiki.debian.org/ServicesSSL In RHEL 7, I notice they have: /etc/pki/tls/certs (local server certs) /etc/pki/tls/private (private keys) and there is no directory with a collection of root certs, just a couple of root bundles with all certs in the same file: /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-bundle.trust.crt The Fedora docs are here: https://fedoraproject.org/wiki/Features/SharedSystemCertificates
You have misunderstood the wiki page. The change for wget in jessie is that it now ignores non-CA certs in /etc/ssl/certs for verification purposes, whereas in wheezy you could also put individual service certs there too and avoid relying on the SSL mafia.
severity 790943 normal thanks Constraints: CA:FALSE". Any program that accepts such certificates as trusted root certificate already has a serious security problem. Therefore I don't think the policy of make-ssl-cert to put certs into /etc/ssl/certs creates additional security issues. I am downgrading the bug accordingly. I am not really against putting server and ca certificate into separate directories. But some Debian-wide default would be nice, of course. Maybe we can discuss that at Debconf?
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. 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
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
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..
On Fri, 03 Jul 2015 10:56:54 +0200 Daniel Pocock <daniel@pocock.pro> wrote: > Package: ssl-cert > Version: 1.0.35 > This package provides the script /usr/sbin/make-ssl-cert > > It creates certificates and puts the public key / certificate PEM file > in /etc/ssl/certs > > The ca-certificates package puts symlinks to CA certificates in the same > location, /etc/ssl/certs > > Some other packages refer to /etc/ssl/certs as a directory of trusted > roots. > Some people suggest using /etc/ssl/ssl.crt or /etc/ssl/public for local > certificate files. > > I did a Google search to try and find out of there is a policy about > this directory and no results were found. So I can't say that this > package is violating any specific policy or what should be done to fix > it, but I do feel the status quo is troublesome. +1. /etc/ssl/certs is generated by ca-certificates, I don't think it should be modified by anyone else. I found a weird bug/conflict as a result. Debian Jessie provides this awesomely convenient setup for Apache. You can literally just enable SSL, and it uses the "snakeoil" (self-signed) certificate created by ssl-cert. (Then Iceweasel/Firefox let you add the server cert when you visit). I'm looking at trusting the snakeoil cert (to get secure Owncloud sync). I tested curl from the server to itself - certificate error. But the snakeoil cert is already in /etc/ssl/certs, so how does this actually work[*]? curl --cacert <certificate file> works fine. Let's poke around... update-ca-certificates # no change update-ca-certificates --fresh # now curl works! without specifying any options. `update-ca-certificates --fresh` is only documented to remove any stale symlinks. It shouldn't suddenly change the trust status of the default snakeoil! It's not a massive security problem because the snakeoil isn't a CA cert. But it's obviously unintended and surprising behavior. You could argue it suggests sloppy coding in ca-certificates as well, but ssl-cert's behavior is just asking for trouble. [*] The "standard", documented way is to copy certs to /usr/local/share/ca-certificates (huh?) and run update-ca-certificates. > Should local certs go in some other directory, +1 > or should other packages > stop trusting everything in /etc/ssl/certs? Btw I don't mind an extra step to trust local certs, so long as there's a documented method I can have confidence in. Alan
Laba diena, Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio. Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą. Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje. Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis. Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis: 1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais. 2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai. 3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus. Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas. Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia. ( Sąrašas prisegtas laiške excel faile ) Parašykite, kurias veiklas išsirinkote ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti Pagarbiai, Tadas Giedraitis Tel. nr. +37067881041
I just came across this while configuring the CA certs for some software. It would be really nice if this security issue were fixed at some point. In the meantime, it looks like /etc/ssl/certs/ca-certificates.crt doesn't have the snake oil certificate (at least on my systems) even though /etc/ssl/cert does have symlinks to it. So I think it might be a reasonable workaround to point software at the single file instead of the directory?
You made a very good investigation on the topic. I agree that a public cert shouldn't be placed into the same folder as CA certs. There is some mention of a weird bug https://serverfault.com/a/840191/442430 Instead I think that both private key and cert should be merged into a one file and placed into /etc/ssl/private/. It looks like there were a lot of discussions but we didn't come to a single agreement about the place to store certs and how to manage them. Please read my proposition here https://github.com/certbot/certbot/issues/1425#issuecomment-1150116062 I'll appreciate any feedback. Regards, Sergey Ponomarev, stokito.com