> 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
a
: 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
> 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
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 wh
> Perhaps cert.pem should just move to examples/ with no default in /etc/ssl.
No. (I know you're ironic.)
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. Usual
> 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,
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
> What threat models do we want to address
The one addressing your maintenance of the certification
infrastructure.
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?
> this is a real problem for real people.
so, expecting a real solution, uhm yes, it's a potion of soluble metal.
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 wh
everyone on the carousel? why not rework the trust model.
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 cour
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
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. Typi
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
> mishandled certificates are such a huge cash cow that no one wants to do
How is this related to OpenBSD?
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.
> > What do you think?
Stop wasting time on this, there are more useful, reasonable and
beautiful places to get lost.
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
flow
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 s
Congrats to raising another time wasting topic for a public commentary.
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 pleth
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
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
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 men
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 ema
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 r
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
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
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, fr
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
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 probab
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 ce
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 option
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 r
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 upgra
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/ce
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 w
40 matches
Mail list logo
