[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when conn

From: David Engster
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
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux)

Lars Magne Ingebrigtsen writes:
> Eli Zaretskii <address@hidden> 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

  openssl s_client -connect news.gmane.org:563


  Certificate chain
  0 s:/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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]