From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.0 required=3.0 tests=BAYES_40,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Mart van de Wege Newsgroups: comp.lang.ada Subject: Re: SweetAda 0.1g released Date: Tue, 17 Nov 2020 14:45:29 +0100 Message-ID: <87wnykp05i.fsf@gaheris.vdwege.eu> References: <46155ba8-785c-4503-81bc-a0a3cf3acd63n@googlegroups.com> <87h7ppowis.fsf@nosuchdomain.example.com> <85d6240f-6877-4883-958a-45eff606abe3n@googlegroups.com> <871rgsqtfv.fsf@gaheris.vdwege.eu> <07d9e1d0-734f-47bf-87e8-33942173036cn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net uZNUWRjOv9FQkkatuxQbtQyEAUo/FvsAMJcZAlts1c5oAsxYPY X-Orig-Path: gaheris.vdwege.eu!not-for-mail Cancel-Lock: sha1:qJXydD4UOVR8OgerxFuJF6AwB/Q= sha1:0Ru0yIuhaMYuFSSxiTi0mknXQKg= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Xref: reader02.eternal-september.org comp.lang.ada:60597 List-Id: Gabriele Galeotti 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.