bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Dmitry Gutov]

And has been doing that ever since NSM patches were installed, IIRC.

Am I doing something wrong?

Looks like this:

Certificate information
Issued by:          news.gmane.org
Issued to:          Gmane
Hostname:           news.gmane.org
Public key:         RSA, signature: RSA-SHA1
Protocol:           TLS1.0, key: DHE-RSA, cipher: AES-128-CBC, mac: SHA1
Security level:     Weak
Valid:              From 2011-12-04 to 2014-12-03


The TLS connection to news.gmane.org:nntp is insecure for the
following reasons:

certificate signer was not found (self-signed)
certificate could not be verified


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-12-18 on axl
Repository revision: 18d4bdf135524f33173caa2ef2164345bd09017d
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> And has been doing that ever since NSM patches were installed, IIRC.
>
> Am I doing something wrong?

Nope.  It's a self-signed certificate.  Press "A" to accept.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Dmitry Gutov]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Nope.  It's a self-signed certificate.  Press "A" to accept.

Okay.  Thanks for the answer.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 18 Dec 2014 15:49:50 +0100
> Cc: 19404@debbugs.gnu.org
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > And has been doing that ever since NSM patches were installed, IIRC.
> >
> > Am I doing something wrong?
> 
> Nope.  It's a self-signed certificate.  Press "A" to accept.

Really?  How can you tell it's self-signed?  Back when I had a problem
with GnuTLS not picking up root certificates, NSM said the same thing:

  Certificate information
  Issued by:          Google Internet Authority G2
  Issued to:          Google Inc
  Hostname:           accounts.google.com
  Public key:         RSA, signature: RSA-SHA1
  Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
  Security level:     Medium
  Valid:              From 2014-12-03 to 2015-03-03


  The TLS connection to accounts.google.com:443 is insecure for the
  following reasons:

  certificate signer was not found (self-signed)
  certificate could not be verified

How this one is different, and are you sure Dmitry shouldn't check his
certificate bundle?

Also, what about this bit:

   Valid:              From 2011-12-04 to 2014-12-03
                                          ^^^^^^^^^^

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Nope.  It's a self-signed certificate.  Press "A" to accept.
>
> Really?  How can you tell it's self-signed?

Because I installed it myself.  :-)

> Also, what about this bit:
>
>    Valid:              From 2011-12-04 to 2014-12-03
>                                           ^^^^^^^^^^

That's odd.  In that case there should be an additional warning for an
expired certificate, but gnutls doesn't seem to offer one.  Ted, do you
know anything about that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  19404@debbugs.gnu.org
> Date: Thu, 18 Dec 2014 17:06:10 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Nope.  It's a self-signed certificate.  Press "A" to accept.
> >
> > Really?  How can you tell it's self-signed?
> 
> Because I installed it myself.  :-)

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?

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Magne Ingebrigtsen]

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Dmitry Gutov]

On 12/18/2014 07:28 PM, Eli Zaretskii wrote:

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

Web browser vendors have simply decided that a self-signed certificate 
is never okay. That's why I'm surprised by the answer to this report.

Also because obtaining a properly signed certificate is relatively easy 
these days.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  19404@debbugs.gnu.org
> Date: Thu, 18 Dec 2014 18:53:07 +0100
> 
> 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.

Too bad.

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

Is this text returned by GnuTLS, or do we produce it in Emacs?  If the
latter, can _we_ somehow distinguish between the two cases and add
some text to that effect?

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this text returned by GnuTLS, or do we produce it in Emacs?

We produce it in Emacs.

> If the latter, can _we_ somehow distinguish between the two cases and
> add some text to that effect?

These are our translation to text from the GnuTLS error messages (which
we have previously translated to symbols).  I had hoped that the :not-ca
case would help, but I've never seen it in the wild.  

  if (EQ (status_symbol, intern (":invalid")))
    return build_string ("certificate could not be verified");

  if (EQ (status_symbol, intern (":revoked")))
    return build_string ("certificate was revoked (CRL)");

  if (EQ (status_symbol, intern (":self-signed")))
    return build_string ("certificate signer was not found (self-signed)");

  if (EQ (status_symbol, intern (":not-ca")))
    return build_string ("certificate signer is not a CA");

  if (EQ (status_symbol, intern (":insecure")))
    return build_string ("certificate was signed with an insecure algorithm");

  if (EQ (status_symbol, intern (":not-activated")))
    return build_string ("certificate is not yet activated");

  if (EQ (status_symbol, intern (":expired")))
    return build_string ("certificate has expired");

  if (EQ (status_symbol, intern (":no-host-match")))
    return build_string ("certificate host does not match hostname");


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ivan Shmakov]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

[…]

 >> If the latter, can _we_ somehow distinguish between the two cases
 >> and add some text to that effect?

 > These are our translation to text from the GnuTLS error messages
 > (which we have previously translated to symbols).  I had hoped that
 > the :not-ca case would help, but I've never seen it in the wild.

[…]

 > if (EQ (status_symbol, intern (":self-signed")))
 >   return build_string ("certificate signer was not found (self-signed)");

 > if (EQ (status_symbol, intern (":not-ca")))
 >   return build_string ("certificate signer is not a CA");

	Presumably the former is returned when the certificate is signed
	by an unknown CA, which /typically/ – but by no means
	/necessarily/ – implies a self-signed certificate.  It’s of
	course possible for the peer’s certificate to be signed by a CA
	not known (or not trusted) by the user.

	The latter would mean that the signing party is not a CA.  That
	is: the signer’s own certificate lacks the CA flag.  (The
	certificate will be also the peer’s own one in the self-signed
	case.)

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

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

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  19404@debbugs.gnu.org
> Date: Thu, 18 Dec 2014 19:57:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this text returned by GnuTLS, or do we produce it in Emacs?
> 
> We produce it in Emacs.
> 
> > If the latter, can _we_ somehow distinguish between the two cases and
> > add some text to that effect?
> 
> These are our translation to text from the GnuTLS error messages (which
> we have previously translated to symbols).  I had hoped that the :not-ca
> case would help, but I've never seen it in the wild.  

What about the "self-signed" part, why is that being reported for
certificates whose authority could not be verified, like in my use
case?  That's not "self-signed" in my book.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

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

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

Eli Zaretskii writes:
>> 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 see now that :self-signed is mapped to
GNUTLS_CERT_SIGNER_NOT_FOUND. This however does not mean that a
certificate is self-signed. See

http://www.gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fstatus_005ft

It simply means: "The certificate’s issuer is not known. This is the
case if the issuer is not included in the trusted certificate list."

It *could* be self-signed. I don't know the best way in libgnutls to
detect this. You probably have to compare issuer and subject, or
similar.

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

David Engster writes:
> It *could* be self-signed. I don't know the best way in libgnutls to
> detect this. You probably have to compare issuer and subject, or
> similar.

So my guess would be: use gnutls_x509_crt_get_dn2 or maybe
gnutls_x509_crt_get_subject and compare to
gnutls_certificate_get_issuer. If equal -> self-signed. But that could
be wrong. Best place is to ask on the GnuTLS list.

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ivan Shmakov]

>>>>> David Engster <deng@randomsample.de> writes:
>>>>> David Engster writes:

 >> It *could* be self-signed. I don't know the best way in libgnutls to
 >> detect this. You probably have to compare issuer and subject, or
 >> similar.

 > So my guess would be: use gnutls_x509_crt_get_dn2 or maybe
 > gnutls_x509_crt_get_subject and compare to
 > gnutls_certificate_get_issuer.  If equal -> self-signed.  But that
 > could be wrong.  Best place is to ask on the GnuTLS list.

	If anything, it’s the respective public key fingerprints that
	are to be compared.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

Ivan Shmakov writes:
>>>>>> David Engster <deng@randomsample.de> writes:
>>>>>> David Engster writes:
>
>  >> It *could* be self-signed. I don't know the best way in libgnutls to
>  >> detect this. You probably have to compare issuer and subject, or
>  >> similar.
>
>  > So my guess would be: use gnutls_x509_crt_get_dn2 or maybe
>  > gnutls_x509_crt_get_subject and compare to
>  > gnutls_certificate_get_issuer.  If equal -> self-signed.  But that
>  > could be wrong.  Best place is to ask on the GnuTLS list.
>
> 	If anything, it’s the respective public key fingerprints that
> 	are to be compared.

Sorry, I don't get it. Which respective public key fingerprints? There's
just one certificate.

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: 19404@debbugs.gnu.org,  larsi@gnus.org,  dgutov@yandex.ru
> Date: Thu, 18 Dec 2014 22:50:22 +0100
> 
> David Engster writes:
> > It *could* be self-signed. I don't know the best way in libgnutls to
> > detect this. You probably have to compare issuer and subject, or
> > similar.
> 
> So my guess would be: use gnutls_x509_crt_get_dn2 or maybe
> gnutls_x509_crt_get_subject and compare to
> gnutls_certificate_get_issuer. If equal -> self-signed. But that could
> be wrong. Best place is to ask on the GnuTLS list.

Thanks, I think we should do that (and also ask).  I'm afraid if we
are too vague or even inaccurate in these prompts (as some Web
browsers already are), too many people will become annoyed and will
simply disregard them, and either always automatically accept the
"Always" alternative, or even disable these checks completely.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: 19404@debbugs.gnu.org,  larsi@gnus.org,  dgutov@yandex.ru
> Date: Thu, 18 Dec 2014 22:40:56 +0100
> 
> I see now that :self-signed is mapped to
> GNUTLS_CERT_SIGNER_NOT_FOUND.

Then the text we produce is misleading, IMO.

> http://www.gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fstatus_005ft
> 
> It simply means: "The certificate’s issuer is not known. This is the
> case if the issuer is not included in the trusted certificate list."

I suggest that we say something like this, indeed.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It simply means: "The certificate’s issuer is not known. This is the
>> case if the issuer is not included in the trusted certificate list."
>
> I suggest that we say something like this, indeed.

However, this means nothing to people who don't know what it already
means, while "self-signed" is something that more people understand.

But the suggestion to only suggest that the certificate may be
self-signed if the issuer and host name are the same may help a bit.
There's quite a few self-signed sites out there where that's not the
case, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Dmitry Gutov]

On 12/19/2014 02:11 PM, Lars Ingebrigtsen wrote:

> There's quite a few self-signed sites out there where that's not the
> case, though.

"certificate’s issuer is not known" would be fine in this case.

Users shouldn't rely on "self-signed" as some proof of validity anyway.

Strictly speaking, it's still insecure, even if only one party may be 
listening.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: David Engster <deng@randomsample.de>,  19404@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Fri, 19 Dec 2014 13:11:46 +0100
> MailScanner-NULL-Check: 1419595943.94089@Frj7Sl8lupuHOmrgKZTQZA
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It simply means: "The certificate’s issuer is not known. This is the
> >> case if the issuer is not included in the trusted certificate list."
> >
> > I suggest that we say something like this, indeed.
> 
> However, this means nothing to people who don't know what it already
> means

The first sentence sounds very clear to me, even to someone who knows
nothing about this.

We could reword the second sentence to say something like

  Please make sure your trusted certificate database is installed and
  up to date.

This should at least give enough "food" to talk to some sysadmin, if
the user doesn't know where the certificates are kept or how to update
them.

> while "self-signed" is something that more people understand.

But it's a lie in this case, or at least might be.

> But the suggestion to only suggest that the certificate may be
> self-signed if the issuer and host name are the same may help a bit.
> There's quite a few self-signed sites out there where that's not the
> case, though.

Then how come they are "self-signed"?  At least the domain should be
the same, no?

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> Date: Fri, 19 Dec 2014 14:20:13 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: David Engster <deng@randomsample.de>, 19404@debbugs.gnu.org
> 
> On 12/19/2014 02:11 PM, Lars Ingebrigtsen wrote:
> 
> > There's quite a few self-signed sites out there where that's not the
> > case, though.
> 
> "certificate’s issuer is not known" would be fine in this case.

"certificate’s issuer is not known or couldn't be verified" is even
better.

> Users shouldn't rely on "self-signed" as some proof of validity anyway.

Agreed.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

Lars Ingebrigtsen writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> It simply means: "The certificate’s issuer is not known. This is the
>>> case if the issuer is not included in the trusted certificate list."
>>
>> I suggest that we say something like this, indeed.
>
> However, this means nothing to people who don't know what it already
> means, while "self-signed" is something that more people understand.

You wish...

> But the suggestion to only suggest that the certificate may be
> self-signed if the issuer and host name are the same may help a bit.
> There's quite a few self-signed sites out there where that's not the
> case, though.

The host name has nothing to do with a certificate being self-signed or
not. Forget actual servers for a moment and look only at the
certificate. There's an 'issuer' and a 'subject'. Both contain
identities in the form of a string like

  /C=NO/ST=Some-State/O=Gmane/CN=news.gmane.org

As you can see, part of that string is the "common name" (CN), which can
be a hostname (maybe with a wildcard), an email address, etc. Whoever
has the private key for that certificate claims the identity for that
CN.

The 'issuer' is the identity who signed that certificate with its own
private key. In real life this should mean that the issuer made sure
that the person who created that certificate with this CN is actually
the administrator for that server, or the person with that e-mail
address.

If a certificate is "self-signed", this means that issuer and subject
are the same entity, i.e., the string in there is identical. There are
some rules how these strings must be compared. I think(!) that if you
simply compare them byte by byte, you should err on the side of
safety. But I would assume there is a function for that in GnuTLS that
adheres to RFC5280 for comparing such things.

As to what messages we should emit in such cases, I think we should
simply say what Firefox says: "The certificate is not trusted because it
is self-signed."

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

David Engster writes:
> If a certificate is "self-signed", this means that issuer and subject
> are the same entity, i.e., the string in there is identical. There are
> some rules how these strings must be compared. I think(!) that if you
> simply compare them byte by byte, you should err on the side of
> safety. But I would assume there is a function for that in GnuTLS that
> adheres to RFC5280 for comparing such things.

I've asked on the GnuTLS mailing list.

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ivan Shmakov]

>>>>> David Engster <deng@randomsample.de> writes:
>>>>> Ivan Shmakov writes:
>>>>> David Engster <deng@randomsample.de> writes:

[…]

 >>> So my guess would be: use gnutls_x509_crt_get_dn2 or maybe
 >>> gnutls_x509_crt_get_subject and compare to
 >>> gnutls_certificate_get_issuer.  If equal -> self-signed.  But that
 >>> could be wrong.  Best place is to ask on the GnuTLS list.

 >> If anything, it’s the respective public key fingerprints that are to
 >> be compared.

 > Sorry, I don't get it.  Which respective public key fingerprints?
 > There's just one certificate.

	Public key fingerprint is a property of, well, the public key, –
	not the certificate.

	But I stand corrected; as it seems, while OpenPGP signatures –
	including those binding user IDs to public keys [1] – allow for
	the signer (issuer) to be identified with a “key ID” (the low
	64 bits SHA-1 of the respective public key’s fingerprint), X.509
	certificates do not offer such an option (e. g., [2].)

	So I guess we should indeed check the DNs.

[1] urn:ietf:rfc:4880, section 11.1 “Transferable Public Keys”.
[2] https://cipherious.wordpress.com/2013/05/13/constructing-an-x-509-certificate-using-asn-1/

-- 
FSF associate member #7257  np. The Talisman — Iron Maiden   … B6A0 230E 334A

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ted Zlatanov]

If I understand correctly, it seems 1) the :self-signed message and
symbol need to be changed, and 2) we're waiting for the GnuTLS
developers to tell us the best way to detect a self-signed certificate.

For (1) I propose using :unknown-ca and "the certificate was signed by
an unknown and therefore untrusted authority"

Ted

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Cc: David Engster <deng@randomsample.de>,  Eli Zaretskii <eliz@gnu.org>,  19404@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Sat, 20 Dec 2014 09:17:05 -0500
> 
> For (1) I propose using :unknown-ca and "the certificate was signed by
> an unknown and therefore untrusted authority"

Sounds good to me, thanks.

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> If I understand correctly, it seems 1) the :self-signed message and
> symbol need to be changed, and 2) we're waiting for the GnuTLS
> developers to tell us the best way to detect a self-signed certificate.
>
> For (1) I propose using :unknown-ca and "the certificate was signed by
> an unknown and therefore untrusted authority"

Sounds good.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[David Engster]

David Engster writes:
> David Engster writes:
>> If a certificate is "self-signed", this means that issuer and subject
>> are the same entity, i.e., the string in there is identical. There are
>> some rules how these strings must be compared. I think(!) that if you
>> simply compare them byte by byte, you should err on the side of
>> safety. But I would assume there is a function for that in GnuTLS that
>> adheres to RFC5280 for comparing such things.
>
> I've asked on the GnuTLS mailing list.

Nick answered, and it's really simple: call gnutls_x509_crt_check_issuer
on the certificate itself (meaning: provide the certificate in question
for both arguments).

-David

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Sat, 20 Dec 2014 22:44:54 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> If I understand correctly, it seems 1) the :self-signed message and
>> symbol need to be changed, and 2) we're waiting for the GnuTLS
>> developers to tell us the best way to detect a self-signed certificate.
>> 
>> For (1) I propose using :unknown-ca and "the certificate was signed by
>> an unknown and therefore untrusted authority"

LI> Sounds good.

On Sun, 21 Dec 2014 18:16:35 +0100 David Engster <deng@randomsample.de> wrote: 

DE> Nick answered, and it's really simple: call gnutls_x509_crt_check_issuer
DE> on the certificate itself (meaning: provide the certificate in question
DE> for both arguments).

Please try the attached patch. I'm not able to test it myself because
I'm traveling, but it should be fairly trivial and addresses both
issues. Feel free to commit it with any changes you want, it's a tiny
change.

gnutls_x509_crt_check_issuer() has been in GnuTLS for all the versions
we support, so there was no need for a version check.

(there was a third issue, the expiration date was wrong, but that's not
as urgent)

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: self-signed.patch --]
[-- Type: text/x-patch, Size: 2999 bytes --]

diff --git a/src/gnutls.c b/src/gnutls.c
index bf9f132..500dbf3 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -154,6 +154,8 @@ enum extra_peer_verification
 	       (gnutls_session_t, gnutls_push_func));
 DEF_GNUTLS_FN (int, gnutls_x509_crt_check_hostname,
 	       (gnutls_x509_crt_t, const char *));
+DEF_GNUTLS_FN (int, gnutls_x509_crt_check_issuer,
+	       (gnutls_x509_crt_t, gnutls_x509_crt_t));
 DEF_GNUTLS_FN (void, gnutls_x509_crt_deinit, (gnutls_x509_crt_t));
 DEF_GNUTLS_FN (int, gnutls_x509_crt_import,
 	       (gnutls_x509_crt_t, const gnutls_datum_t *,
@@ -269,6 +271,7 @@ enum extra_peer_verification
   LOAD_GNUTLS_FN (library, gnutls_transport_set_pull_function);
   LOAD_GNUTLS_FN (library, gnutls_transport_set_push_function);
   LOAD_GNUTLS_FN (library, gnutls_x509_crt_check_hostname);
+  LOAD_GNUTLS_FN (library, gnutls_x509_crt_check_issuer);
   LOAD_GNUTLS_FN (library, gnutls_x509_crt_deinit);
   LOAD_GNUTLS_FN (library, gnutls_x509_crt_import);
   LOAD_GNUTLS_FN (library, gnutls_x509_crt_init);
@@ -365,6 +368,7 @@ enum extra_peer_verification
 #define fn_gnutls_strerror			gnutls_strerror
 #define fn_gnutls_transport_set_ptr2		gnutls_transport_set_ptr2
 #define fn_gnutls_x509_crt_check_hostname	gnutls_x509_crt_check_hostname
+#define fn_gnutls_x509_crt_check_issuer         gnutls_x509_crt_check_issuer
 #define fn_gnutls_x509_crt_deinit		gnutls_x509_crt_deinit
 #define fn_gnutls_x509_crt_get_activation_time  gnutls_x509_crt_get_activation_time
 #define fn_gnutls_x509_crt_get_dn               gnutls_x509_crt_get_dn
@@ -985,6 +989,10 @@ enum extra_peer_verification
   if (EQ (status_symbol, intern (":self-signed")))
     return build_string ("certificate signer was not found (self-signed)");
 
+  if (EQ (status_symbol, intern (":unknown-ca")))
+    return build_string ("the certificate was signed by an unknown "
+                         "and therefore untrusted authority");
+
   if (EQ (status_symbol, intern (":not-ca")))
     return build_string ("certificate signer is not a CA");
 
@@ -1029,7 +1037,7 @@ enum extra_peer_verification
     warnings = Fcons (intern (":revoked"), warnings);
 
   if (verification & GNUTLS_CERT_SIGNER_NOT_FOUND)
-    warnings = Fcons (intern (":self-signed"), warnings);
+    warnings = Fcons (intern (":unknown-ca"), warnings);
 
   if (verification & GNUTLS_CERT_SIGNER_NOT_CA)
     warnings = Fcons (intern (":not-ca"), warnings);
@@ -1047,6 +1055,13 @@ enum extra_peer_verification
       CERTIFICATE_NOT_MATCHING)
     warnings = Fcons (intern (":no-host-match"), warnings);
 
+  /* This could get called in the INIT stage, when the certificate is
+     not yet set. */
+  if (XPROCESS (proc)->gnutls_certificate != NULL &&
+      gnutls_x509_crt_check_issuer(XPROCESS (proc)->gnutls_certificate,
+                                   XPROCESS (proc)->gnutls_certificate))
+    warnings = Fcons (intern (":self-signed"), warnings);
+
   if (!NILP (warnings))
     result = list2 (intern (":warnings"), warnings);
 

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Ted Zlatanov]

The main part is done:

commit 3b7eed4ebb3c18799ec791d0c6bd53c019f48f73
Author: Ted Zlatanov <tzz@lifelogs.com>
Date:   Thu Jan 15 09:41:58 2015 -0500

    Flag :unknown-ca and :self-signed SSL certs  (Bug#19404)

    Fixes: debbugs:19404

    * gnutls.c (init_gnutls_functions): Import gnutls_x509_crt_check_issuer.
    (Fgnutls_peer_status): Use it to set the :self-signed flag.
    Rename the previous :self-signed to :unknown-ca.
    (Fgnutls_peer_status_warning_describe): Explain :unknown-ca flag.

(I'm not sure about the Fixes: header, so I added the bug number in the
first line of the commit message too.)

On Wed, 24 Dec 2014 08:11:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> (there was a third issue, the expiration date was wrong, but that's not
TZ> as urgent)

Lars, you added that date code, right?  Could you check?  I'll leave
this bug open until that's fixed.

Thanks!
Ted

bug#19404: 25.0.50; Gnus shows self-signed certificate warning when connecting to Gmane

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> TZ> (there was a third issue, the expiration date was wrong, but that's not
> TZ> as urgent)
>
> Lars, you added that date code, right?  Could you check?  I'll leave
> this bug open until that's fixed.

I just checked the expiration on news.gmane.org, and it says:

Valid:              From 2015-01-13 to 2018-01-12

And I think that's right...

Does anybody have a test case for an incorrect expiry?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no