On Tue, Jun 1, 2021 at 11:29 PM Rich Freeman wrote:
> On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote:
> >>
> >> And another "wondering" - all the warnings about trusting self signed
> >> certs seem a bit self serving. Yes, they are trying to certify who you
> >> are, but at the expense of prob
On 6/2/21 1:48 AM, Fannys wrote:
Tech should be based on tech. Not faith and trust on the other party.
That's where detection of breach of trust comes into play. Thus DNSSEC
and things related.
--
Grant. . . .
unix || die
On 6/2/21 1:21 AM, J. Roeleveld wrote:
Do you know which extensions add this?
I don't remember exactly (they weren't compatible with Firefox 78) but
from memory, they were from the CZ NIC operator. They have many things
related to this.
--
Grant. . . .
unix || die
On June 2, 2021 1:51:06 AM UTC, Grant Taylor
wrote:
>On 6/1/21 3:38 PM, Michael Orlitzky wrote:
>> *Any* CA can just generate a new key and sign the corresponding
>> certificate.
>
>This is where what can /technically/ be done diverges from what is
>/allowed/ to be done.
>
>CAs adhering to the
On Wednesday, June 2, 2021 12:28:49 AM CEST Fannys wrote:
> On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" wrote:
> >On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
> >> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote
> >>
> >> > 125 config files in /etc/ssl/certs ne
On Wednesday, June 2, 2021 3:51:06 AM CEST Grant Taylor wrote:
> On 6/1/21 3:38 PM, Michael Orlitzky wrote:
> > All browsers will treat their fake certificate corresponding to the
> > fake key on their fake web server as completely legitimate. The "real"
> > original key that you generated has no s
On 6/1/21 3:38 PM, Michael Orlitzky wrote:
*Any* CA can just generate a new key and sign the corresponding
certificate.
This is where what can /technically/ be done diverges from what is
/allowed/ to be done.
CAs adhering to the CA/B Forum's requirements on CAA records mean that
they aren't
On 1/6/21 9:29 pm, Rich Freeman wrote:
> On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote:
>>> And another "wondering" - all the warnings about trusting self signed
>>> certs seem a bit self serving. Yes, they are trying to certify who you
>>> are, but at the expense of probably allowing access
On June 1, 2021 4:45:45 AM UTC, "J. Roeleveld" wrote:
>On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
>> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote
>>
>> > 125 config files in /etc/ssl/certs needs update.
>> >
>> > For certificates I would expect the old and i
On Tue, 2021-06-01 at 15:25 -0600, Grant Taylor wrote:
>
> The proper way configure certificates is:
>
> 1) Create a key on the local server.
> 2) Create a Certificate Signing Request (a.k.a. CSR) which references,
> but does not include, the key.
> 3) As a CA to sign the CSR.
> 4) Use the c
On 5/31/21 11:15 PM, William Kenworthy wrote:
And another "wondering" - all the warnings about trusting self signed
certs seem a bit self serving.
No, it's not self serving.
Considerably more people than public certificate authorities bemoan self
signed certificates.
Consider this:
1) You
On 5/29/21 12:26 AM, Walter Dnes wrote:
Looking through them is "interesting". There seem to be a lot of
/etc/ssl/certs/.0 files, where "?" is either a random number
or a lower case letter.
They aren't random at all. They are a fingerprint (hash) of signing (?)
certificates. The fi
On Tue, Jun 1, 2021 at 7:59 AM Adam Carter wrote:
>>
>> And another "wondering" - all the warnings about trusting self signed
>> certs seem a bit self serving. Yes, they are trying to certify who you
>> are, but at the expense of probably allowing access to your
>> communications by "authorised pa
On Tue, Jun 1, 2021 at 8:16 AM Michael Orlitzky wrote:
>
> On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote:
> >
> > So what would you recommend for someone in the case Joost cites? I'm in that
> > position, being a home user of a small network but no registered Internet
> > name.
> >
>
> A
Karl:
> Michael Orilitzky:
Sorry, I mistyped, it should be: Peter Humphrey
> ...
> > * The LetsEncrypt certificates expire after three months, as opposedÂ
> > to 10+ years for a self-signed certificate. You're supposed toÂ
> > automate this... by running a script as root that takes input f
Michael Orilitzky:
...
> * The LetsEncrypt certificates expire after three months, as opposedÂ
> to 10+ years for a self-signed certificate. You're supposed toÂ
> automate this... by running a script as root that takes input fromÂ
> the web? I'd rather not do that.
You can run most part
Joost:
> On Tuesday, June 1, 2021 12:44:47 PM CEST k...@aspodata.se wrote:
... [ about letsencrypt ] ...
> It's not that easy to do it with internal-only systems as Let's Encrypt
> requires the hostname to be known externally.
> And there are plenty of devices you do not want the whole internet to
On Tuesday, 1 June 2021 13:16:59 BST Michael Orlitzky wrote:
> On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote:
> > So what would you recommend for someone in the case Joost cites? I'm in
> > that position, being a home user of a small network but no registered
> > Internet name.
>
> A sel
On Tue, 2021-06-01 at 13:02 +0100, Peter Humphrey wrote:
>
> So what would you recommend for someone in the case Joost cites? I'm in that
> position, being a home user of a small network but no registered Internet
> name.
>
A self-signed certificate combined with a browser extension that lets
On Tuesday, 1 June 2021 12:40:28 BST Michael Orlitzky wrote:
> On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote:
> > It's not that easy to do it with internal-only systems as Let's Encrypt
> > requires the hostname to be known externally.
> > And there are plenty of devices you do not want the
>
> And another "wondering" - all the warnings about trusting self signed
> certs seem a bit self serving. Yes, they are trying to certify who you
> are, but at the expense of probably allowing access to your
> communications by "authorised parties" (such as commercial entities
> purchasing access
On Tue, 2021-06-01 at 13:17 +0200, J. Roeleveld wrote:
>
> It's not that easy to do it with internal-only systems as Let's Encrypt
> requires the hostname to be known externally.
> And there are plenty of devices you do not want the whole internet to know
> about.
>
And in this situation LetsE
On Tuesday, June 1, 2021 12:44:47 PM CEST k...@aspodata.se wrote:
> BillK:
> ...
>
> > And another "wondering" - all the warnings about trusting self signed
> > certs seem a bit self serving. Yes, they are trying to certify who you
> > are, but at the expense of probably allowing access to your
>
BillK:
...
> And another "wondering" - all the warnings about trusting self signed
> certs seem a bit self serving. Yes, they are trying to certify who you
> are, but at the expense of probably allowing access to your
> communications by "authorised parties" (such as commercial entities
> purchasin
On 1/6/21 12:45 pm, J. Roeleveld wrote:
> On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
>> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote
>>
>>> 125 config files in /etc/ssl/certs needs update.
>>>
>>> For certificates I would expect the old and invalid ones to be
On Saturday, May 29, 2021 8:26:57 AM CEST Walter Dnes wrote:
> On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote
>
> > 125 config files in /etc/ssl/certs needs update.
> >
> > For certificates I would expect the old and invalid ones to be replaced
> > by newer ones without user int
On Sat, May 29, 2021 at 03:08:39AM +0200, zca...@gmail.com wrote
>
> 125 config files in /etc/ssl/certs needs update.
>
> For certificates I would expect the old and invalid ones to be replaced
> by newer ones without user intervention.
Looking through them is "interesting". There seem to be
125 config files in /etc/ssl/certs needs update.
For certificates I would expect the old and invalid ones to be replaced
by newer ones without user intervention.
bb.zven
28 matches
Mail list logo
