Re: SweetAda 0.1g released

[Mart van de Wege <mvdwege@gmail.com>]

Gabriele Galeotti <gabriele.galeotti.xyz@gmail.com> writes:

> On Tuesday, November 17, 2020 at 9:30:05 AM UTC+1, Mart van de Wege wrote:
>
>> That's because Let's Encrypt issued you a certificate for 
>> www.sweetada.org, with www.sweetada.org as a Subject Alternative Name. 
>> 
>> Subject: CN = www.sweetada.org 
>> 
>> X509v3 Subject Alternative Name: 
>> DNS:www.sweetada.org 
>> 
>> I'd say that's a broken certificate. I have no clue why they would issue 
>> it that way, unless you made a mistake in your Certificate Signing 
>> Request. Unfortunately, I do not use Letsencrypt, so no clue where it 
>> went wrong. The norm is to have a cert with Subject (in this case) 
>> sweetada.org with www.sweetada.org as the SAN. 
>> 
>> Mart 
>> 
>> -- 
>> "We will need a longer wall when the revolution comes." 
>> --- AJS, quoting an uncertain source.
>
> Many thanks for your hints.
> If an error exists, it's obviously mine.
> I'll take into account what you say e maybe one of next weekends I'll try to correct everything.
> In the meantime, use only the (apparent) secure https://www.sweetada.org connection.
> Best regards
> G

Since we have the key fingerprints, and the certificate is the same,
both connection are equally secure.

Don't let yourself be frightened by the security theatre around
certificates. The *only* thing they prove is that a private key that
belongs to the name in the public key that was certified by a CA
(Letsencrypt in this case) is on the server you're connecting to. That's
all. There is nothing more the SSL/TLS protocols can prove.

So the server answering to sweetada.org has access to the same key as
the server answering to www.sweetada.org. And we know it's the same
server. Since Letsencrypt certified that the key belonging to the
www.sweetada.org certificate should be the one presented, and it is,
that means both servers are equally 'secure'.

Note that I said nothing about whether or not it is a malicious server
or not; that's not something SSL/TLS can answer.

So don't worry. We know about it, and letsencrypt should normally let
you fix this easily.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.