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
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
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
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
everyone on the carousel? why not rework the trust model.
this is a real problem for real people.
so, expecting a real solution, uhm yes, it's a potion of soluble metal.
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
On 2015-07-30 23:17, Stuart Henderson wrote:
On 2015-07-30, Vadim Zhukov persg...@gmail.com wrote:
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
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
2015/07/31 15:33 li...@wrant.com:
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?
: 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
On 2015-07-31, Benny Lofgren bl-li...@lofgren.biz 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
On 2015-07-30, Vadim Zhukov persg...@gmail.com 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
What threat models do we want to address
The one addressing your maintenance of the certification
infrastructure.
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
Perhaps cert.pem should just move to examples/ with no default in /etc/ssl.
No. (I know you're ironic.)
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
2015-07-30 3:02 GMT+03:00 trondd tro...@kagu-tsuchi.com:
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
On 2015-07-30, Vadim Zhukov persg...@gmail.com wrote:
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Ted Unangst t...@tedunangst.com wrote:
Michael McConville wrote:
Another meat could be, why you're using self-signed certificates?
Given the plethora of
2015-07-31 0:17 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Vadim Zhukov persg...@gmail.com wrote:
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Ted Unangst t...@tedunangst.com wrote:
Michael McConville wrote:
Another meat could be, why
2015-07-31 0:48 GMT+03:00 Vadim Zhukov persg...@gmail.com:
2015-07-31 0:17 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Vadim Zhukov persg...@gmail.com wrote:
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Ted Unangst t...@tedunangst.com
Congrats to raising another time wasting topic for a public commentary.
What do you think?
Stop wasting time on this, there are more useful, reasonable and
beautiful places to get lost.
2015/07/31 6:49 Vadim Zhukov persg...@gmail.com:
[...]
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
On Thu, July 30, 2015 5:17 pm, Stuart Henderson wrote:
On 2015-07-30, Vadim Zhukov persg...@gmail.com wrote:
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Ted Unangst t...@tedunangst.com wrote:
Michael McConville wrote:
Another meat could be, why you're
mishandled certificates are such a huge cash cow that no one wants to do
How is this related to OpenBSD?
2015/07/31 8:34 li...@wrant.com:
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
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
On Thu, Jul 30, 2015 at 7:47 PM, Michael McConville
mmcco...@sccs.swarthmore.edu 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,
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
On 2015-07-30, Ted Unangst t...@tedunangst.com 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.
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
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
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
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
Stuart Henderson wrote:
On 2015-07-30, Ted Unangst t...@tedunangst.com 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
2015-07-30 20:16 GMT+03:00 Stuart Henderson s...@spacehopper.org:
On 2015-07-30, Ted Unangst t...@tedunangst.com 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
On Thu, Jul 30, 2015 at 05:16:30PM +, Stuart Henderson wrote:
On 2015-07-30, Ted Unangst t...@tedunangst.com 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
2015-07-31 3:15 GMT+03:00 Joel Rees joel.r...@gmail.com:
2015/07/31 6:49 Vadim Zhukov persg...@gmail.com:
[...]
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
2015/07/31 9:15 Joel Rees joel.r...@gmail.com:
2015/07/31 6:49 Vadim Zhukov persg...@gmail.com:
[...]
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
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
40 matches
Mail list logo
