GNU bug report logs -
#19404
25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Thu, 18 Dec 2014 11:53:01 UTC
Severity: normal
Found in version 25.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Lars Magne Ingebrigtsen writes:
> Eli Zaretskii <eliz <at> 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
This bug report was last modified 10 years and 192 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.