Re: Maintaining CAs not in cert.pem
> Is there a place to put them that is automatically read in addition to > cert.pem? There is also the question of removing some of them and keeping these removed between updates, e.g. a domain plundering hosting company that is not trust worthy. One thing that comes to mind is the recent sed -i addition.
Re: Maintaining CAs not in cert.pem
If you are doing it right your CA private key is on a different machine without network connectivity. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Giancarlo Razzolini Sent: Friday, July 31, 2015 9:34 AM To: Peter Hessler; li...@wrant.com Cc: misc@openbsd.org Subject: Re: Maintaining CAs not in cert.pem Em 31-07-2015 03:07, Peter Hessler escreveu: > this is a real problem for real people. Which was pretty much solved with PKP [0]. As I mentioned, custom CA's have their uses, but in the end, they are just one more thing waiting to bite you in the ass. You can pretend to have a decent OPSEC for a while, but in the end you CA private key will end up being on the same machine your certs are being used. With PKP you can disregard the CA completely, but your certificate will be recognized on pretty much every device. It's nice that the discussion spawned a change in the way how the certs.pem is handled on system upgrades, but moving it to examples is not a solution (shouldn't even be discussed ironically). The bottom line is, want your own CA, deal with it. [0] http://tools.ietf.org/html/rfc7469
Re: Maintaining CAs not in cert.pem
> one more thing waiting to > bite you in the ass Correct, and resource wasteful maintainership is not that valuable to end users who stumble in their feet anyway. If trying to solve it, please show a solution that is not burning developer time, as it will get abandoned soon or later, there is no entity to pick foreign bureau submissions and manage these you know and importing third party crap is... crap.
Re: Maintaining CAs not in cert.pem
Em 31-07-2015 03:07, Peter Hessler escreveu: > this is a real problem for real people. Which was pretty much solved with PKP [0]. As I mentioned, custom CA's have their uses, but in the end, they are just one more thing waiting to bite you in the ass. You can pretend to have a decent OPSEC for a while, but in the end you CA private key will end up being on the same machine your certs are being used. With PKP you can disregard the CA completely, but your certificate will be recognized on pretty much every device. It's nice that the discussion spawned a change in the way how the certs.pem is handled on system upgrades, but moving it to examples is not a solution (shouldn't even be discussed ironically). The bottom line is, want your own CA, deal with it. [0] http://tools.ietf.org/html/rfc7469
Re: Maintaining CAs not in cert.pem
> Perhaps cert.pem should just move to examples/ with no default in /etc/ssl. No. (I know you're ironic.)
Re: Maintaining CAs not in cert.pem
On 2015-07-30, Vadim Zhukov wrote:
> Well, I see four scenarios:
>
> 1. Using the defaults supplied with OpenBSD only. Typical for home/personal
> use.
>
> 2. Use the defaults supplied with OpenBSD, and one or more additional
> CAs. Typical for corporate use.
>
> 3. Use personal set of CAs. Usually means either white-, or
> blacklisting entries from "base" certs pack.
> 1. Have "base" certs installed into /etc/examples/certs.pem.
> 2. Additional certs, if any, should go into /etc/ssl/local.pem.
> 3. Have sysmerge handle certs specially: comparing not (old)
> /etc/examples/cert.pem with /etc/ssl/cert.pem, but
> /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In
> case they do match, sysmerge would regenerate /etc/ssl/cert.pem by
> concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem.
>
> What do you think?
This doesn't handle the "blacklisting" case and I think will be difficult
to understand as it's very different to standard use of sysmerge.
If sysmerge was going to have special handling for certificates,
it could have a different merge handler than sdiff that treats it as
more than just a text file. ("add Honest Achmed?", "remove Xyz CA?") ...
I don't know if that's a good idea though.
Perhaps cert.pem should just move to examples/ with no default in /etc/ssl.
It would be an extra hoop for users to jump through but that would free up
/etc/ssl/cert.pem to either be managed manually (create the file or symlink
to examples) or via packages (probably install under an /etc prefix like
the firmware packages; @sample isn't strong enough for CA certs). The
latter would be useful for people who don't care and just want the
bundle from Mozilla, or for people who want tight control and distribute
their own local CA package.
Re: Maintaining CAs not in cert.pem
> We have directories like this (but without removing locally-added > files). Finally some body addressed file management, meaning a template system or formalisation is about to be forming. > The single-file approach at least makes things simple for the majority > who don't edit the file though, and works with our existing upgrade tools. Now what about editor safety as stupidly expressed by another member on the list?
Re: Maintaining CAs not in cert.pem
On 2015-07-31, Benny Lofgren wrote: > So I borrowed an idea from how the Courier MTA/IMAP/POP3 server manages > some of its configuration files: > > The system could check whether /etc/ssl/cert.pem (or whatever path any > particular application provides) is a regular file, in which case > business as usual. > > But if it is a *directory* then LibreSSL would internally concatenate > all of its contents (or, for example, just all *.pem files) when > initializing the certificate chain. We have directories like this for fontconfig settings, but they don't work very well in practice with updates - if a file is removed, sysmerge puts it back. Sysmerge could have some different handling but it needs some way to decide whether or not to install a file that is present in etc.tgz but not on disk; is it new or was it an old file that the sysadmin wanted to disable? It would also need to gain the ability to *remove* files from the directory (but without removing locally-added files). The single-file approach at least makes things simple for the majority who don't edit the file though, and works with our existing upgrade tools.
Re: Maintaining CAs not in cert.pem
> What threat models do we want to address The one addressing your maintenance of the certification infrastructure.
Re: Maintaining CAs not in cert.pem
2015/07/31 15:33 : > > everyone on the carousel? why not rework the trust model. Okay, I'll play. What threat models do we want to address uhm, at the library level?
Re: Maintaining CAs not in cert.pem
> this is a real problem for real people. so, expecting a real solution, uhm yes, it's a potion of soluble metal.
Re: Maintaining CAs not in cert.pem
On 2015-07-30 23:17, Stuart Henderson wrote: > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. > >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. There are for sure use cases (I've got several myself right off the bat) that would benefit from a simpler solution. Of course appending your own certs to the huge /etc/ssl/cert.pem file does work, but even with the assistance of sysmerge it is a clunky, potentially error prone maneuver... So I borrowed an idea from how the Courier MTA/IMAP/POP3 server manages some of its configuration files: The system could check whether /etc/ssl/cert.pem (or whatever path any particular application provides) is a regular file, in which case business as usual. But if it is a *directory* then LibreSSL would internally concatenate all of its contents (or, for example, just all *.pem files) when initializing the certificate chain. That "simple" mechanism would give the system administrator an application agnostic/transparent way to manage additions to the certificate store. I put simple within quotes though, because then I went into the source to see if I could quickly put together a proof of concept diff for discussion purposes... [ insert audience's laughter here ] To probably no ones surprise (including my own) I quickly gave up, realizing what an insanely complex piece of software it is! My head hurt just trying to follow along what was happening and who called what when why... I'm definitely not the right person to fiddle with that piece of code without some serious reading up, and of course any change made without a complete grasp of the entire library is almost certain to have unintended and potentially very serious side effects just about anywhere... So as I would only be doing everybody a disservice by providing code at this stage, I'm just throwing the idea out there for now. Is it a good idea or will it just confuse people and system? Is it even doable without breaking compatibility? If so, is it worth the effort? Regards, /Benny
Re: Maintaining CAs not in cert.pem
everyone on the carousel? why not rework the trust model.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 09:17:23PM +, Stuart Henderson wrote: > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > If I remember correctly, the possibility of use SSL_CERT_FILE (from env) in libssl was been removed. So if the application don't let set a cafile (from argument, configfile...) libssl don't use another cert_file than /etc/ssl/cert.pem. -- Sebastien Marie
Re: Maintaining CAs not in cert.pem
this is a real problem for real people. On 2015 Jul 31 (Fri) at 02:33:00 +0300 (+0300), li...@wrant.com wrote: :Congrats to raising another time wasting topic for a public commentary. : -- Love thy neighbor as thyself, but choose your neighborhood. -- Louise Beal
Re: Maintaining CAs not in cert.pem
2015/07/31 9:15 "Joel Rees" : > > 2015/07/31 6:49 "Vadim Zhukov" : > > > > [...] > > > > > Well, I see four scenarios: > > > > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. > > > > 2. Use the defaults supplied with OpenBSD, and one or more additional > > CAs. Typical for corporate use. > > > > 3. Use personal set of CAs. Usually means either white-, or > > blacklisting entries from "base" certs pack. > > > > After more thinking I see that symlink idea is not good. But we can do > > some other thing: > > > > 1. Have "base" certs installed into /etc/examples/certs.pem. > > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > > 3. Have sysmerge handle certs specially: comparing not (old) > > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > > > What do you think? > > I know my opinions don't count much here, but it seems to me that mishandled certificates are such a huge cash cow that no one wants to do them right. Until the cash cow dies, anything we try now is likely to be wrong. > > With that caveat, try your ideas on your own system. You'll need to add some scripts of your own to extend what sysmerge and other tools do. Post to the list about how it works for you over the next year or so. > > That's my suggestion. I'm playing Don Quixote on list again. I did not mean that as an attack on Vadim, but it sure came out that way. My apologies to the list, and to Vadim. Joel Rees
Re: Maintaining CAs not in cert.pem
2015-07-31 3:15 GMT+03:00 Joel Rees : > 2015/07/31 6:49 "Vadim Zhukov" : >> >> [...] >> >> Well, I see four scenarios: >> >> 1. Using the defaults supplied with OpenBSD only. Typical for > home/personal use. >> >> 2. Use the defaults supplied with OpenBSD, and one or more additional >> CAs. Typical for corporate use. >> >> 3. Use personal set of CAs. Usually means either white-, or >> blacklisting entries from "base" certs pack. >> >> After more thinking I see that symlink idea is not good. But we can do >> some other thing: >> >> 1. Have "base" certs installed into /etc/examples/certs.pem. >> 2. Additional certs, if any, should go into /etc/ssl/local.pem. >> 3. Have sysmerge handle certs specially: comparing not (old) >> /etc/examples/cert.pem with /etc/ssl/cert.pem, but >> /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In >> case they do match, sysmerge would regenerate /etc/ssl/cert.pem by >> concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. >> >> What do you think? > > I know my opinions don't count much here, but it seems to me that > mishandled certificates are such a huge cash cow that no one wants to do > them right. Until the cash cow dies, anything we try now is likely to be > wrong. > > With that caveat, try your ideas on your own system. You'll need to add > some scripts of your own to extend what sysmerge and other tools do. Post > to the list about how it works for you over the next year or so. > > That's my suggestion. Discussed off-list. There was a misunderstanding that was (I hope) fixed. -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
> mishandled certificates are such a huge cash cow that no one wants to do How is this related to OpenBSD?
Re: Maintaining CAs not in cert.pem
2015/07/31 6:49 "Vadim Zhukov" : > > [...] > > Well, I see four scenarios: > > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. > > 2. Use the defaults supplied with OpenBSD, and one or more additional > CAs. Typical for corporate use. > > 3. Use personal set of CAs. Usually means either white-, or > blacklisting entries from "base" certs pack. > > After more thinking I see that symlink idea is not good. But we can do > some other thing: > > 1. Have "base" certs installed into /etc/examples/certs.pem. > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > 3. Have sysmerge handle certs specially: comparing not (old) > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > What do you think? I know my opinions don't count much here, but it seems to me that mishandled certificates are such a huge cash cow that no one wants to do them right. Until the cash cow dies, anything we try now is likely to be wrong. With that caveat, try your ideas on your own system. You'll need to add some scripts of your own to extend what sysmerge and other tools do. Post to the list about how it works for you over the next year or so. That's my suggestion. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Maintaining CAs not in cert.pem
> > What do you think? Stop wasting time on this, there are more useful, reasonable and beautiful places to get lost.
Re: Maintaining CAs not in cert.pem
2015/07/31 8:34 : > > Congrats to raising another time wasting topic for a public commentary. > Do you mean that CAs, certificates, and how they are handled are topics that don't need talking about? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Maintaining CAs not in cert.pem
2015-07-31 0:48 GMT+03:00 Vadim Zhukov : > 2015-07-31 0:17 GMT+03:00 Stuart Henderson : >> On 2015-07-30, Vadim Zhukov wrote: >>> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : On 2015-07-30, Ted Unangst wrote: > Michael McConville wrote: >> > Another meat could be, why you're using self-signed certificates? >> > Given the plethora of options for getting free (valid) certificates. >> >> He mentioned in his original email that it's a requirement where he >> works. That's common, from what I hear, although probably not the >> safest. > > I would consider a cert signed by somebody I actually trust (me) safer > than > delegating that trust to 300 strangers. I think cert.pem should move to the etc set, so you can remove CAs from the file (as well as add new ones) without risk of those changes getting reverted. Downside: CA changes will then only take effect after running sysmerge. Is that a problem? >>> >>> I think it is. This is the same as with /etc/examples: less stuff to >>> merge, less errors to happen. >> >> cert.pem is pretty much a required file, we can't just move it to examples/. >> For people who don't touch it, it's a simple no-touch sysmerge update. >> For people who do, having sysmerge ask about merging it is a lot safer >> than just overwriting. > > No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I > think that its current contents could be provided in other way... > >>> I'd ask another question: why can't software use /etc/ssl/myown.pem, >>> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >>> "trust" and "untrust" operations as simple as possible. Noone in >>> healthy mind would place junk in /etc/ssl anyway, right? >> >> Some software allows you to set a different certificate file; other >> software doesn't. Patching everything in ports that verifies SSL certs >> to allow the user to specify an alternative file would just be insane. > > Hm-m, I always tried to live in a separate room with SSL beasts. Now I > realize that I saved a lot of nerves myself, and as a result I'm > living in a pink pony world. Thanks for getting back to the ground. > > I thought that there was some "default" in OpenSSL (and its > decendants) that programs tends to use. Now I realize there is no such > place. Okay, this variant gets busted. > >> And of course then there's no single way to tell programs to use the >> alternative file; "ftp -S cafile=/path/to/cert.pem", >> "env SSL_CERT_FILE=/path/to/cert.pem lynx" >> >>> Or we may ship /etc/ssl/base.pem in base tgz, and install >>> /etc/ssl/cert.pem -> base.pem at installation time. This way things >>> will work by default, and if you need to have your own trust path, you >>> just change symlink. What do you think? >> >> That doesn't really help. One common scenario is wanting to add a >> single CA to the standard file, but otherwise pick up updates (e.g. with >> sysmerge), this method doesn't allow that. > > Well, I see four scenarios: Those should be "three", of course. :) > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal > use. > > 2. Use the defaults supplied with OpenBSD, and one or more additional > CAs. Typical for corporate use. > > 3. Use personal set of CAs. Usually means either white-, or > blacklisting entries from "base" certs pack. > > After more thinking I see that symlink idea is not good. But we can do > some other thing: > > 1. Have "base" certs installed into /etc/examples/certs.pem. > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > 3. Have sysmerge handle certs specially: comparing not (old) > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > What do you think? -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
Congrats to raising another time wasting topic for a public commentary.
Re: Maintaining CAs not in cert.pem
2015-07-31 0:17 GMT+03:00 Stuart Henderson : > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >>> On 2015-07-30, Ted Unangst wrote: Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers. >>> >>> I think cert.pem should move to the etc set, so you can remove >>> CAs from the file (as well as add new ones) without risk of those >>> changes getting reverted. >>> >>> Downside: CA changes will then only take effect after running >>> sysmerge. Is that a problem? >> >> I think it is. This is the same as with /etc/examples: less stuff to >> merge, less errors to happen. > > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I think that its current contents could be provided in other way... >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. Hm-m, I always tried to live in a separate room with SSL beasts. Now I realize that I saved a lot of nerves myself, and as a result I'm living in a pink pony world. Thanks for getting back to the ground. I thought that there was some "default" in OpenSSL (and its decendants) that programs tends to use. Now I realize there is no such place. Okay, this variant gets busted. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. Well, I see four scenarios: 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. 2. Use the defaults supplied with OpenBSD, and one or more additional CAs. Typical for corporate use. 3. Use personal set of CAs. Usually means either white-, or blacklisting entries from "base" certs pack. After more thinking I see that symlink idea is not good. But we can do some other thing: 1. Have "base" certs installed into /etc/examples/certs.pem. 2. Additional certs, if any, should go into /etc/ssl/local.pem. 3. Have sysmerge handle certs specially: comparing not (old) /etc/examples/cert.pem with /etc/ssl/cert.pem, but /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In case they do match, sysmerge would regenerate /etc/ssl/cert.pem by concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. What do you think? -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
On Thu, July 30, 2015 5:17 pm, Stuart Henderson wrote: > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >>> On 2015-07-30, Ted Unangst wrote: Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) > certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers. >>> >>> I think cert.pem should move to the etc set, so you can remove >>> CAs from the file (as well as add new ones) without risk of those >>> changes getting reverted. >>> >>> Downside: CA changes will then only take effect after running >>> sysmerge. Is that a problem? >> >> I think it is. This is the same as with /etc/examples: less stuff to >> merge, less errors to happen. > > cert.pem is pretty much a required file, we can't just move it to > examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. > >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. > Well I didn't expect this to take off into larger conversation... :) Work requirements aside, for personal use, I prefer to use my own CA over self signed certificates because I can manage that centrally. I don't have to tell applications to allow self-signed certs which might apply to all domains and not just my own, or respond to warnings about them. Also it's more fail-safe. If I forget to re-add my CA (or use sysmerge if we go that way) then I'll see warnings or errors I won't be expecting. I initially though cert.pem was managed by sysmerge. That would be a solution I think would work well. Tim.
Re: Maintaining CAs not in cert.pem
On 2015-07-30, Vadim Zhukov wrote: > 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >> On 2015-07-30, Ted Unangst wrote: >>> Michael McConville wrote: > Another meat could be, why you're using self-signed certificates? > Given the plethora of options for getting free (valid) certificates. He mentioned in his original email that it's a requirement where he works. That's common, from what I hear, although probably not the safest. >>> >>> I would consider a cert signed by somebody I actually trust (me) safer than >>> delegating that trust to 300 strangers. >> >> I think cert.pem should move to the etc set, so you can remove >> CAs from the file (as well as add new ones) without risk of those >> changes getting reverted. >> >> Downside: CA changes will then only take effect after running >> sysmerge. Is that a problem? > > I think it is. This is the same as with /etc/examples: less stuff to > merge, less errors to happen. cert.pem is pretty much a required file, we can't just move it to examples/. For people who don't touch it, it's a simple no-touch sysmerge update. For people who do, having sysmerge ask about merging it is a lot safer than just overwriting. > I'd ask another question: why can't software use /etc/ssl/myown.pem, > or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make > "trust" and "untrust" operations as simple as possible. Noone in > healthy mind would place junk in /etc/ssl anyway, right? Some software allows you to set a different certificate file; other software doesn't. Patching everything in ports that verifies SSL certs to allow the user to specify an alternative file would just be insane. And of course then there's no single way to tell programs to use the alternative file; "ftp -S cafile=/path/to/cert.pem", "env SSL_CERT_FILE=/path/to/cert.pem lynx" > Or we may ship /etc/ssl/base.pem in base tgz, and install > /etc/ssl/cert.pem -> base.pem at installation time. This way things > will work by default, and if you need to have your own trust path, you > just change symlink. What do you think? That doesn't really help. One common scenario is wanting to add a single CA to the standard file, but otherwise pick up updates (e.g. with sysmerge), this method doesn't allow that.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 05:16:30PM +, Stuart Henderson wrote: > On 2015-07-30, Ted Unangst wrote: > > Michael McConville wrote: > >> > Another meat could be, why you're using self-signed certificates? > >> > Given the plethora of options for getting free (valid) certificates. > >> > >> He mentioned in his original email that it's a requirement where he > >> works. That's common, from what I hear, although probably not the > >> safest. > > > > I would consider a cert signed by somebody I actually trust (me) safer than > > delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? I would like to see cert.pm become a "managed" file. FWIW OK rpe@ -- -=[rpe]=-
Re: Maintaining CAs not in cert.pem
2015-07-30 20:16 GMT+03:00 Stuart Henderson : > On 2015-07-30, Ted Unangst wrote: >> Michael McConville wrote: >>> > Another meat could be, why you're using self-signed certificates? >>> > Given the plethora of options for getting free (valid) certificates. >>> >>> He mentioned in his original email that it's a requirement where he >>> works. That's common, from what I hear, although probably not the >>> safest. >> >> I would consider a cert signed by somebody I actually trust (me) safer than >> delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? I think it is. This is the same as with /etc/examples: less stuff to merge, less errors to happen. I'd ask another question: why can't software use /etc/ssl/myown.pem, or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make "trust" and "untrust" operations as simple as possible. Noone in healthy mind would place junk in /etc/ssl anyway, right? Or we may ship /etc/ssl/base.pem in base tgz, and install /etc/ssl/cert.pem -> base.pem at installation time. This way things will work by default, and if you need to have your own trust path, you just change symlink. What do you think? > Index: base/mi > === > RCS file: /cvs/src/distrib/sets/lists/base/mi,v > retrieving revision 1.716 > diff -u -p -r1.716 mi > --- base/mi 16 Jul 2015 21:28:06 - 1.716 > +++ base/mi 30 Jul 2015 17:14:15 - > @@ -221,7 +221,6 @@ > ./etc/skel/.ssh > ./etc/ssh > ./etc/ssl > -./etc/ssl/cert.pem > ./etc/ssl/lib > ./etc/ssl/private > ./etc/systrace > Index: etc/mi > === > RCS file: /cvs/src/distrib/sets/lists/etc/mi,v > retrieving revision 1.199 > diff -u -p -r1.199 mi > --- etc/mi 3 Jul 2015 22:52:52 - 1.199 > +++ etc/mi 30 Jul 2015 17:14:15 - > @@ -42,6 +42,7 @@ > ./etc/spwd.db > ./etc/ssh/ssh_config > ./etc/ssh/sshd_config > +./etc/ssl/cert.pem > ./etc/ssl/openssl.cnf > ./etc/ssl/x509v3.cnf > ./etc/syslog.conf -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
Stuart Henderson wrote: > On 2015-07-30, Ted Unangst wrote: > > Michael McConville wrote: > >> > Another meat could be, why you're using self-signed certificates? > >> > Given the plethora of options for getting free (valid) certificates. > >> > >> He mentioned in his original email that it's a requirement where he > >> works. That's common, from what I hear, although probably not the > >> safest. > > > > I would consider a cert signed by somebody I actually trust (me) safer than > > delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? Not in my mind. I'm all for this; it's outside my department or I would have suggested the same.
Re: Maintaining CAs not in cert.pem
On 2015-07-30, Ted Unangst wrote: > Michael McConville wrote: >> > Another meat could be, why you're using self-signed certificates? >> > Given the plethora of options for getting free (valid) certificates. >> >> He mentioned in his original email that it's a requirement where he >> works. That's common, from what I hear, although probably not the >> safest. > > I would consider a cert signed by somebody I actually trust (me) safer than > delegating that trust to 300 strangers. I think cert.pem should move to the etc set, so you can remove CAs from the file (as well as add new ones) without risk of those changes getting reverted. Downside: CA changes will then only take effect after running sysmerge. Is that a problem? Index: base/mi === RCS file: /cvs/src/distrib/sets/lists/base/mi,v retrieving revision 1.716 diff -u -p -r1.716 mi --- base/mi 16 Jul 2015 21:28:06 - 1.716 +++ base/mi 30 Jul 2015 17:14:15 - @@ -221,7 +221,6 @@ ./etc/skel/.ssh ./etc/ssh ./etc/ssl -./etc/ssl/cert.pem ./etc/ssl/lib ./etc/ssl/private ./etc/systrace Index: etc/mi === RCS file: /cvs/src/distrib/sets/lists/etc/mi,v retrieving revision 1.199 diff -u -p -r1.199 mi --- etc/mi 3 Jul 2015 22:52:52 - 1.199 +++ etc/mi 30 Jul 2015 17:14:15 - @@ -42,6 +42,7 @@ ./etc/spwd.db ./etc/ssh/ssh_config ./etc/ssh/sshd_config +./etc/ssl/cert.pem ./etc/ssl/openssl.cnf ./etc/ssl/x509v3.cnf ./etc/syslog.conf
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 13:58, Kimmo Paasiala escreveu: > That depends on the use case of the certificate. Use of self-signed > certificate is no less secure than an "official" one as far as the > actual encryption on the transport layer goes. It's only a question if > the user trusts the authenticity of the self-signed certificate and > the issuer of certificate is prepared to educate his/her users what a > self-signed certificate is and why they should trust it. Yes, self-signed certs have their uses. VPN's come to mind. Custom CA's for intercepting, also. Since most people don't even care about tls warnings, they got their uses. But, as it is becoming clearer and clearer to the OP, you need to maintain it yourself, and not screw up. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
Ted Unangst wrote: > Michael McConville wrote: > > > Another meat could be, why you're using self-signed certificates? > > > Given the plethora of options for getting free (valid) certificates. > > > > He mentioned in his original email that it's a requirement where he > > works. That's common, from what I hear, although probably not the > > safest. > > I would consider a cert signed by somebody I actually trust (me) safer > than delegating that trust to 300 strangers. I was thinking of offices that make employees install their root certificate so that their encrypted traffic can be filtered/monitored.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 7:47 PM, Michael McConville wrote: > Giancarlo Razzolini wrote: >> Em 30-07-2015 09:15, trondd escreveu: >> > I guess the meat of the question is "is certs.pem the only location >> > for CAs used by the system?" (ignoring application certificate >> > stores, ie. Firefox or java). >> >> Another meat could be, why you're using self-signed certificates? >> Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. > That depends on the use case of the certificate. Use of self-signed certificate is no less secure than an "official" one as far as the actual encryption on the transport layer goes. It's only a question if the user trusts the authenticity of the self-signed certificate and the issuer of certificate is prepared to educate his/her users what a self-signed certificate is and why they should trust it. -Kimmo
Re: Maintaining CAs not in cert.pem
Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers.
Re: Maintaining CAs not in cert.pem
Giancarlo Razzolini wrote: > Em 30-07-2015 09:15, trondd escreveu: > > I guess the meat of the question is "is certs.pem the only location > > for CAs used by the system?" (ignoring application certificate > > stores, ie. Firefox or java). > > Another meat could be, why you're using self-signed certificates? > Given the plethora of options for getting free (valid) certificates. He mentioned in his original email that it's a requirement where he works. That's common, from what I hear, although probably not the safest.
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 09:15, trondd escreveu: > I guess the meat of the question is "is certs.pem the only location for > CAs used by the system?" (ignoring application certificate stores, ie. > Firefox or java). Another meat could be, why you're using self-signed certificates? Given the plethora of options for getting free (valid) certificates. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
2015-07-30 3:02 GMT+03:00 trondd : > I have my own CA for home use and my work also has their own CA and > intermediate certificates. What is the correct way of maintaining the > certificates so that the system always knows about them? I've been > appending them to /etc/ssl/cert.pem but it gets replaced every update (not > even maintained with sysmerge since it comes for libcrypto and not the etc > package). > > Is there a place to put them that is automatically read in addition to > cert.pem? It depends on software you're using, actually. Qt 4 and 5 look at the whole /etc/ssl (without subdirs) for certificates, for example. -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
On Thu, July 30, 2015 4:13 am, Raf Czlonka wrote: > > Why now simply put it in siteXX.tgz? > >> Tim. > > Raf > I guess the meat of the question is "is certs.pem the only location for CAs used by the system?" (ignoring application certificate stores, ie. Firefox or java). I guess tweaking my upgrade processes/scripts isn't that hard if everything has to be in certs.pem. Just don't want to go in that direction if there is an alternative already built in. Tim.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 01:02:52AM BST, trondd wrote: > I have my own CA for home use and my work also has their own CA and > intermediate certificates. What is the correct way of maintaining the > certificates so that the system always knows about them? I've been > appending them to /etc/ssl/cert.pem but it gets replaced every update > (not even maintained with sysmerge since it comes for libcrypto and > not the etc package). > > Is there a place to put them that is automatically read in addition to > cert.pem? Why now simply put it in siteXX.tgz? > Tim. Raf
Maintaining CAs not in cert.pem
I have my own CA for home use and my work also has their own CA and intermediate certificates. What is the correct way of maintaining the certificates so that the system always knows about them? I've been appending them to /etc/ssl/cert.pem but it gets replaced every update (not even maintained with sysmerge since it comes for libcrypto and not the etc package). Is there a place to put them that is automatically read in addition to cert.pem? Tim.
