From: David Engster <deng@randomsample.de>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: 19404@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane
Date: Thu, 18 Dec 2014 21:20:05 +0100 [thread overview]
Message-ID: <871tnwoglm.fsf@engster.org> (raw)
In-Reply-To: <m3zjakq1z0.fsf@stories.gnus.org> (Lars Magne Ingebrigtsen's message of "Thu, 18 Dec 2014 18:53:07 +0100")
Lars Magne Ingebrigtsen writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> OK, let me rephrase: How can a user, a mere mortal, like myself or
>> Dmitry, tell that this certificate is OK, while the one I was
>> presented in my problem is not?
>
> That's not generally possible. Unfortunately there's no difference
> between a certificate signed by a CA that you don't happen to have in
> your CA bundle, and a self-signed certificate. Unless I've
> misunderstood something.
>
> I think that's one of many unfortunate design choices made when the
> certificate system was set up.
>
> So the "(self-signed)" string we have in our warnings should perhaps be
> changed to "(possibly self-signed)".
Just to make a few things clear: A 'self-signed' certificate simply
means that a certificate is signed with its own private key. You can
easily identify them by looking at the 'Issuer' and 'Subject' - they are
identical:
openssl s_client -connect news.gmane.org:563
[...]
Certificate chain
0 s:/C=NO/ST=Some-State/O=Gmane/CN=news.gmane.org
i:/C=NO/ST=Some-State/O=Gmane/CN=news.gmane.org
If you connect to a service secured with such a certificate, you'll be
greeted with a certificate chain with a depth of '0', only containing
this one certificate (so it's actually not a chain). Self-signed
certificates are by default never trustworthy, since anyone can create
them.
The only way to have a certificate that is trusted by default is to have
it signed by a trustworthy certificate authority (CA). The issuer must
hence be different from the subject. Technically, such a certificate
authority presents itself also as a certificate, but one that is only
used to sign other certificates; it is never used directly as a server
certificate. So in this case, you will actually have *a chain* of
certificates with a trusted "root CA" at the top (there can be many
intermediate certificate). That CA at the top presents itself as a
self-signed certificate, and it is only made trustworthy because it is
marked as such by another authority (Mozilla, Debian, etc.) in some kind
of certificate storage.
I don't know GnuTLS, but my guess(!) would be like this:
> if (EQ (status_symbol, intern (":invalid")))
> return build_string ("certificate could not be verified");
This means that the root CA is not trusted, or that some intermediate
certificate is missing, so that you do not have a chain of trust.
> if (EQ (status_symbol, intern (":self-signed")))
> return build_string ("certificate signer was not found (self-signed)");
Self-signed, never trusted by default.
> if (EQ (status_symbol, intern (":not-ca")))
> return build_string ("certificate signer is not a CA");
The root certificate is not a CA, meaning it misses some extensions that
are necessary for a CA. It's no wonder you've never seen this. I can
only imagine this to happen with very old (version 1) CAs.
-David
next prev parent reply other threads:[~2014-12-18 20:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 11:52 bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane Dmitry Gutov
2014-12-18 14:49 ` Lars Magne Ingebrigtsen
2014-12-18 15:00 ` Dmitry Gutov
2014-12-18 15:56 ` Eli Zaretskii
2014-12-18 16:06 ` Lars Magne Ingebrigtsen
2014-12-18 17:28 ` Eli Zaretskii
2014-12-18 17:53 ` Lars Magne Ingebrigtsen
2014-12-18 17:56 ` Eli Zaretskii
2014-12-18 18:57 ` Lars Magne Ingebrigtsen
2014-12-18 19:10 ` Ivan Shmakov
2014-12-18 20:30 ` Eli Zaretskii
2014-12-18 20:20 ` David Engster [this message]
2014-12-18 20:52 ` Eli Zaretskii
2014-12-18 21:40 ` David Engster
2014-12-18 21:50 ` David Engster
2014-12-18 22:04 ` Ivan Shmakov
2014-12-18 22:47 ` David Engster
2014-12-19 17:32 ` Ivan Shmakov
2014-12-19 8:28 ` Eli Zaretskii
2014-12-19 8:30 ` Eli Zaretskii
2014-12-19 12:11 ` Lars Ingebrigtsen
2014-12-19 12:20 ` Dmitry Gutov
2014-12-19 14:46 ` Eli Zaretskii
2014-12-19 14:40 ` Eli Zaretskii
2014-12-19 16:55 ` David Engster
2014-12-19 17:17 ` David Engster
2014-12-21 17:16 ` David Engster
2014-12-18 17:56 ` Dmitry Gutov
2014-12-20 14:17 ` Ted Zlatanov
2014-12-20 14:47 ` Eli Zaretskii
2014-12-20 21:44 ` Lars Ingebrigtsen
2014-12-24 13:11 ` Ted Zlatanov
2015-01-15 14:45 ` Ted Zlatanov
2015-01-16 0:23 ` Lars Magne Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871tnwoglm.fsf@engster.org \
--to=deng@randomsample.de \
--cc=19404@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).