bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Eli Zaretskii
Subject: bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane
Date: Thu, 18 Dec 2014 22:52:51 +0200

> From: David Engster <deng@randomsample.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  19404@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Thu, 18 Dec 2014 21:20:05 +0100
> 
> 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.

Do you understand why I got the same "self-signed" indication for a
certificate whose chain couldn't be verified because the root
certificates were not available?  E.g., remove or rename your bundle,
then try "M-x eww" to some HTTPS address -- you will see the
"self-signed" indication in that case as well.  Why does this happen?

> 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.

But we get both of these when the chain couldn't be verified.  Why?





reply via email to

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