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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19404 in the body.
You can then email your comments to 19404 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 11:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 18 Dec 2014 11:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 14:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> 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
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Thu, 18 Dec 2014 15:01:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
bug acknowledged by developer.
(Thu, 18 Dec 2014 15:01:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 19404-done <at> debbugs.gnu.org (full text, mbox):
Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
> Nope. It's a self-signed certificate. Press "A" to accept.
Okay. Thanks for the answer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 15:58:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 18 Dec 2014 15:49:50 +0100
> Cc: 19404 <at> debbugs.gnu.org
>
> Dmitry Gutov <dgutov <at> 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
^^^^^^^^^^
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 16:07:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 17:29:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: dgutov <at> yandex.ru, 19404 <at> debbugs.gnu.org
> Date: Thu, 18 Dec 2014 17:06:10 +0100
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 17:54:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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)".
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 17:57:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 17:58:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: dgutov <at> yandex.ru, 19404 <at> debbugs.gnu.org
> Date: Thu, 18 Dec 2014 18:53:07 +0100
>
> 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.
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 18:58:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 19:12:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 19404 <at> debbugs.gnu.org (full text, mbox):
>>>>> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>>>>> Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 20:21:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 20:31:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: dgutov <at> yandex.ru, 19404 <at> debbugs.gnu.org
> Date: Thu, 18 Dec 2014 19:57:28 +0100
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 20:53:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 19404 <at> debbugs.gnu.org, dgutov <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 21:42:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
>> From: David Engster <deng <at> randomsample.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 19404 <at> debbugs.gnu.org, dgutov <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 21:51:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 22:06:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 19404 <at> debbugs.gnu.org (full text, mbox):
>>>>> David Engster <deng <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 18 Dec 2014 22:48:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Ivan Shmakov writes:
>>>>>> David Engster <deng <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 08:30:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: 19404 <at> debbugs.gnu.org, larsi <at> gnus.org, dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 08:31:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: 19404 <at> debbugs.gnu.org, larsi <at> gnus.org, dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 12:13:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 12:21:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 14:41:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: David Engster <deng <at> randomsample.de>, 19404 <at> debbugs.gnu.org, dgutov <at> yandex.ru
> Date: Fri, 19 Dec 2014 13:11:46 +0100
> MailScanner-NULL-Check: 1419595943.94089 <at> Frj7Sl8lupuHOmrgKZTQZA
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 14:47:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 19 Dec 2014 14:20:13 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: David Engster <deng <at> randomsample.de>, 19404 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 16:56:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen writes:
> Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 17:18:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 19 Dec 2014 17:33:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 19404 <at> debbugs.gnu.org (full text, mbox):
>>>>> David Engster <deng <at> randomsample.de> writes:
>>>>> Ivan Shmakov writes:
>>>>> David Engster <deng <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Sat, 20 Dec 2014 14:17:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Sat, 20 Dec 2014 14:48:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 19404 <at> debbugs.gnu.org (full text, mbox):
> From: Ted Zlatanov <tzz <at> lifelogs.com>
> Cc: David Engster <deng <at> randomsample.de>, Eli Zaretskii <eliz <at> gnu.org>, 19404 <at> debbugs.gnu.org, dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Sat, 20 Dec 2014 21:46:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Ted Zlatanov <tzz <at> 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/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Sun, 21 Dec 2014 17:17:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 19404 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Wed, 24 Dec 2014 13:12:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 19404 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 20 Dec 2014 22:44:54 +0100 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
LI> Ted Zlatanov <tzz <at> 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 <at> 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
[self-signed.patch (text/x-patch, inline)]
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);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Thu, 15 Jan 2015 14:46:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 19404 <at> debbugs.gnu.org (full text, mbox):
The main part is done:
commit 3b7eed4ebb3c18799ec791d0c6bd53c019f48f73
Author: Ted Zlatanov <tzz <at> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19404; Package
emacs.
(Fri, 16 Jan 2015 00:24:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 19404 <at> debbugs.gnu.org (full text, mbox):
Ted Zlatanov <tzz <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 13 Feb 2015 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 190 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.