bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

Today I recompiled emacs from the trunk. Since then I cannot send
emails anymore. Instead I get the error message

gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.
gnutls.el: (err=[-48] Key usage violation in certificate has been detected.) boot: (:priority NORMAL :hostname foo.bar.com :loglevel 0 :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :verify-hostname-error nil :callbacks nil)
gnutls-negotiate: GnuTLS error: #<process smtpmail>, -48
gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet was received. [922 times]

Previously, I had no such problems.

In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-07-07 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_GB.utf8
  value of $LANG: en_US.ISO-8859-15
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-9-unix
  default enable-multibyte-characters: t

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Today I recompiled emacs from the trunk. Since then I cannot send
> emails anymore. Instead I get the error message
>
> gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.
> gnutls.el: (err=[-48] Key usage violation in certificate has been detected.) boot: (:priority NORMAL :hostname foo.bar.com :loglevel 0 :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :verify-hostname-error nil :callbacks nil)
> gnutls-negotiate: GnuTLS error: #<process smtpmail>, -48
> gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet was received. [922 times]
>
> Previously, I had no such problems.

Ted, do you know what this means?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Today I recompiled emacs from the trunk. Since then I cannot send
> emails anymore. Instead I get the error message
>
> gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

Could you (setq debug-on-error t) and post the resulting backtrace you
get when trying to send email?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

Reading

http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2789

this probably means that the certificate offered by the SMTP server is
invalid.  However, smtpmail should detect this, and try to proceed
without encryption if this happens.  I'll try to fix that if you can
give me a backtrace.

In the meantime (as a workaround), if you

(setq smtpmail-stream-type 'plain)

then you should be able to send email again.

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

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

> However, smtpmail should detect this, and try to proceed without
> encryption if this happens.

I think I've now fixed this problem.  Could you try to update your bzr
Emacs and see whether sending email (without any workarounds) works now
for you?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Thu Jul 7 2011 Lars Magne Ingebrigtsen wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > However, smtpmail should detect this, and try to proceed without
> > encryption if this happens.
> 
> I think I've now fixed this problem.  Could you try to update your bzr
> Emacs and see whether sending email (without any workarounds) works now
> for you?

Thanks a lot for looking into this. I am sorry, I can only test your
new code in a couple of days when I am back home. In the meanwhile,
I am attaching a backtrace, see below.

Roland



Debugger entered--Lisp error: (gnutls-error #<process smtpmail> -48)
  signal(gnutls-error (#<process smtpmail> -48))
  gnutls-negotiate(:process #<process smtpmail> :hostname "foo.bar.com" :keylist nil)
  network-stream-open-starttls("smtpmail" #<buffer *trace of SMTP session to foo.bar.com*> "foo.bar.com" 465 (:type nil :return-list t :capability-command "EHLO regnitz\r\n" :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities t :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate t :use-starttls-if-possible t))
  open-network-stream("smtpmail" #<buffer *trace of SMTP session to foo.bar.com*> "foo.bar.com" 465 :type nil :return-list t :capability-command "EHLO regnitz\r\n" :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities t :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate t :use-starttls-if-possible t)
  byte-code("\306\307\310\b\"!\x11r	q\210\311\x12\312 \210)\313\314	\b\v\315\f\316\311\317\307\320\321 \"\322\323\324\325\326\311\327\330\331\311\332\311&\x16\211\x15@\211\x16@\204L\0\333\334\335\rA\336\"\203I\0\335\rA\336\"\202J\0\337\"\210\340\x0e@\341\"\210\335\rA\342\"\x1eA\343\x0eA!\211\x1eB\204l\0\333\334\307\344\x0eA\"\"\210\x0eB\345Y\203|\0\333\334\307\346\x0eA\"\"\210*r	q\210\347\350\211\"\210\351\352!\210e\x16*\335\rA\353\"\x1eC\343\x0eC!\211\x1eB\203\245\0\x0eB\345Y\203\262\0\354\x0e@\307\355\321 \"\"\210\202+\x01\356\357\360\335\rA\353\"\361\"\"\362\x1eD\211\x1eE\203*\x01\x0eE@\x16D\363 p\x1eF\x1eG\364\216\365\x0eH!\210\366\367\360\x0eD\370\362O\371\"\"+\211\x1eIG\372U\203\363\0\x0eI@\x16I\x0eI\203 \x01\x0eI:\203\x04\x01\x0eI@\202\x06\x01\x0eI\373>\203\x15\x01\x0eI\x0eJB\x16J\202 \x01\x0eK\203 \x01\374\375\x0eI\"\210)\x0eEA\211\x16E\204\306\0**\376\x0e@\x0eJ\b\v\x0eL%\x16M\377\x0eJ\235\204H\x01\201U\0\x0eJ\235\203R\x01\354\x0e@\307\201V\0!\"\210\x0eN\203s\x01\201W\0\x0eJ\235\204i\x01\201X\0\x0eJ\235\203s\x01\354\x0e@\307\201Y\0!\"\210\201Z\0\x0eJ\235\203\206\x01\354\x0e@\307\201[\0!\"\210\201\\\0\x0eJ\235\204\233\x01\201]\0\201\\\0\x0eJ\"\203\263\x01\307\201^\0r\x0eOq\210deZ\201_\0ed\"\\)\"\202\264\x01\357\201`\0\x0eJ\235\203\301\x01\357\202\302\x01\357\x1eP\x1eQ\201a\0\x0e@\307\201b\0\x0eR\x0eQ\x0eP$\"\210\201c\0\201d\0\x0e@!\211\x15!\204.\x02\x0eM\203%\x02\x0eL\204%\x02\r@\201e\0U\203%\x02\201a\0\x0e@\201f\0\"\210\201d\0\x0e@!\210\201g\0\x0e@!\210\362\x16@\333\334\201h\0\x0eS\x0eO\311#\"\210\202.\x02\333\334\201i\0\r!\"\210*\201j\0\211\x1eT\x0eS8\203\257\x02\201a\0\x0e@\307\201k\0\201l\0\x0eT\x0eS8!\"\"\210\201c\0\201d\0\x0e@!\211\x15!\204\246\x02\x0eM\203\235\x02\x0eL\204\235\x02\r@\201m\0U\203\235\x02\201a\0\x0e@\201f\0\"\210\201d\0\x0e@!\210\201g\0\x0e@!\210\362\x16@\333\334\201h\0\x0eS\x0eO\311#\"\210\202\246\x02\333\334\201i\0\r!\"\210\x0eTT\211\x16T\2025\x02)\354\x0e@\201n\0\"\210\201o\0\x0e@\x0eO\"\210\354\x0e@\201p\0\"\210)\362\207" [host process-buffer buffer-undo-list port smtpmail-stream-type result get-buffer-create format "*trace of SMTP session to %s*" t erase-buffer open-network-stream "smtpmail" :type :return-list :capability-command "EHLO %s\r\n" smtpmail-fqdn :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate :use-starttls-if-possible throw done plist-get :error "Unable to contact server" set-process-filter smtpmail-process-filter :greeting smtpmail-response-code "No greeting: %s" 400 "Connection not allowed: %s" set-buffer-process-coding-system raw-text-unix make-local-variable smtpmail-read-point :capabilities smtpmail-command-or-throw "HELO %s" delete "" split-string "\r\n" ...] 24)
  smtpmail-via-smtp((#("rwinkler@niu.edu" 0 16 (fontified t))) #<buffer  smtpmail temp>)
  smtpmail-send-it()
  mail-send()
  call-interactively(mail-send nil nil)

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Debugger entered--Lisp error: (gnutls-error #<process smtpmail> -48)
>   signal(gnutls-error (#<process smtpmail> -48))
>   gnutls-negotiate(:process #<process smtpmail> :hostname "foo.bar.com" :keylist nil)

Right.  It bugged out where I guessed it must have, so I think this is
probably fixed now.  Could you check and report back?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 963 bytes --]

On Sun Jul 10 2011 Lars Magne Ingebrigtsen wrote:
> "Roland Winkler" <winkler@gnu.org> writes:
> 
> > Debugger entered--Lisp error: (gnutls-error #<process smtpmail> -48)
> >   signal(gnutls-error (#<process smtpmail> -48))
> >   gnutls-negotiate(:process #<process smtpmail> :hostname "foo.bar.com"
> :keylist nil)
> 
> Right.  It bugged out where I guessed it must have, so I think this is
> probably fixed now.  Could you check and report back?

I recompiled emacs from the trunk today. Unfortunately, emacs simply
hangs now. So I set debug-on-quit to t, which gave me the first
backtrace attached below.

Then I also tried your other suggestion

  (setq smtpmail-stream-type 'plain)

which resulted in the error

  Sending failed: 530 Must issue a STARTTLS command first

see the second backtrace.

Now I am using GNU Emacs 23.3.1 for sending this email.
So in that sense I am fairly confident that nothing is wrong with
the SMTP server I am using.

Roland



[-- Attachment #2: quit.txt --]
[-- Type: application/octet-stream, Size: 3611 bytes --]

[-- Attachment #3: error.txt --]
[-- Type: application/octet-stream, Size: 339 bytes --]

Debugger entered--Lisp error: (error "Sending failed: 530 Must issue a STARTTLS command first")
  signal(error ("Sending failed: 530 Must issue a STARTTLS command first"))
  error("Sending failed: %s" "530 Must issue a STARTTLS command first")
  smtpmail-send-it()
  mail-send()
  vm-mail-send()
  call-interactively(vm-mail-send nil nil)

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> I recompiled emacs from the trunk today. Unfortunately, emacs simply
> hangs now. So I set debug-on-quit to t, which gave me the first
> backtrace attached below.

> Debugger entered--Lisp error: (quit)
>   make-network-process(:name "smtpmail" :buffer #<buffer *trace of SMTP session to foo.bar.com*> :host "foo.bar.com" :service 465)

Hm.  It's hanging in the connect call itself to the SMTP server?  That's
rather odd.

If you eval the following

(make-network-process :name "smtpmail" :buffer (get-buffer-create "foo") :host "foo.bar.com" :service 465)

does it hang?

> Then I also tried your other suggestion
>
>   (setq smtpmail-stream-type 'plain)
>
> which resulted in the error
>
>   Sending failed: 530 Must issue a STARTTLS command first
>
> see the second backtrace.

Yes, your SMTP server apparently requires STARTTLS, but the built-in
GnuTLS support isn't able to negotiate a connection -- I'm guessing
because of a buggy SMTP server certificate.  But that doesn't explain
the apparent hanging in `make-network-process' itself, which is just
bizarre.

Try evaluating this:

(defun gnutls-available-p () nil)

If you have gnutls-cli installed (and you apparently have since it works
in Emacs 23), that should disable the built-in GnuTLS library.  Are you
able to send mail then?
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Mon Jul 11 2011 Lars Magne Ingebrigtsen wrote:
> If you eval the following
> 
> (make-network-process :name "smtpmail" :buffer (get-buffer-create "foo") :host
> "foo.bar.com" :service 465)
> 
> does it hang?

Yes, this hangs, too. (A backtrace doesn't give anything useful
beyond the call of make-network-process.)

> Try evaluating this:
> 
> (defun gnutls-available-p () nil)

This gives me the backtrace below.

Roland



Debugger entered--Lisp error: (wrong-type-argument processp nil)
  process-buffer(nil)
  network-stream-get-response(nil 197 "^[0-9]+ .*\r\n")
  network-stream-open-starttls("smtpmail" #<buffer *trace of SMTP session to foo.bar.com*> "foo.bar.com" 465 (:type nil :return-list t :capability-command "EHLO regnitz\r\n" :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities t :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate t :use-starttls-if-possible t))
  open-network-stream("smtpmail" #<buffer *trace of SMTP session to foo.bar.com*> "foo.bar.com" 465 :type nil :return-list t :capability-command "EHLO regnitz\r\n" :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities t :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate t :use-starttls-if-possible t)
  byte-code("\306\307\310\b\"!\x11r	q\210\311\x12\312 \210)\313\314	\b\v\315\f\316\311\317\307\320\321 \"\322\323\324\325\326\311\327\330\331\311\332\311&\x16\211\x15@\211\x16@\204L\0\333\334\335\rA\336\"\203I\0\335\rA\336\"\202J\0\337\"\210\340\x0e@\341\"\210\335\rA\342\"\x1eA\343\x0eA!\211\x1eB\204l\0\333\334\307\344\x0eA\"\"\210\x0eB\345Y\203|\0\333\334\307\346\x0eA\"\"\210*r	q\210\347\350\211\"\210\351\352!\210e\x16*\335\rA\353\"\x1eC\343\x0eC!\211\x1eB\203\245\0\x0eB\345Y\203\262\0\354\x0e@\307\355\321 \"\"\210\202+\x01\356\357\360\335\rA\353\"\361\"\"\362\x1eD\211\x1eE\203*\x01\x0eE@\x16D\363 p\x1eF\x1eG\364\216\365\x0eH!\210\366\367\360\x0eD\370\362O\371\"\"+\211\x1eIG\372U\203\363\0\x0eI@\x16I\x0eI\203 \x01\x0eI:\203\x04\x01\x0eI@\202\x06\x01\x0eI\373>\203\x15\x01\x0eI\x0eJB\x16J\202 \x01\x0eK\203 \x01\374\375\x0eI\"\210)\x0eEA\211\x16E\204\306\0**\376\x0e@\x0eJ\b\v\x0eL%\x16M\377\x0eJ\235\204H\x01\201U\0\x0eJ\235\203R\x01\354\x0e@\307\201V\0!\"\210\x0eN\203s\x01\201W\0\x0eJ\235\204i\x01\201X\0\x0eJ\235\203s\x01\354\x0e@\307\201Y\0!\"\210\201Z\0\x0eJ\235\203\206\x01\354\x0e@\307\201[\0!\"\210\201\\\0\x0eJ\235\204\233\x01\201]\0\201\\\0\x0eJ\"\203\263\x01\307\201^\0r\x0eOq\210deZ\201_\0ed\"\\)\"\202\264\x01\357\201`\0\x0eJ\235\203\301\x01\357\202\302\x01\357\x1eP\x1eQ\201a\0\x0e@\307\201b\0\x0eR\x0eQ\x0eP$\"\210\201c\0\201d\0\x0e@!\211\x15!\204.\x02\x0eM\203%\x02\x0eL\204%\x02\r@\201e\0U\203%\x02\201a\0\x0e@\201f\0\"\210\201d\0\x0e@!\210\201g\0\x0e@!\210\362\x16@\333\334\201h\0\x0eS\x0eO\311#\"\210\202.\x02\333\334\201i\0\r!\"\210*\201j\0\211\x1eT\x0eS8\203\257\x02\201a\0\x0e@\307\201k\0\201l\0\x0eT\x0eS8!\"\"\210\201c\0\201d\0\x0e@!\211\x15!\204\246\x02\x0eM\203\235\x02\x0eL\204\235\x02\r@\201m\0U\203\235\x02\201a\0\x0e@\201f\0\"\210\201d\0\x0e@!\210\201g\0\x0e@!\210\362\x16@\333\334\201h\0\x0eS\x0eO\311#\"\210\202\246\x02\333\334\201i\0\r!\"\210\x0eTT\211\x16T\2025\x02)\354\x0e@\201n\0\"\210\201o\0\x0e@\x0eO\"\210\354\x0e@\201p\0\"\210)\362\207" [host process-buffer buffer-undo-list port smtpmail-stream-type result get-buffer-create format "*trace of SMTP session to %s*" t erase-buffer open-network-stream "smtpmail" :type :return-list :capability-command "EHLO %s\r\n" smtpmail-fqdn :end-of-command "^[0-9]+ .*\r\n" :success "^2.*\n" :always-query-capabilities :starttls-function #[(capabilities) "\301\302\b\"\205\b\0\303\207" [capabilities string-match "-STARTTLS" "STARTTLS\r\n"] 3] :client-certificate :use-starttls-if-possible throw done plist-get :error "Unable to contact server" set-process-filter smtpmail-process-filter :greeting smtpmail-response-code "No greeting: %s" 400 "Connection not allowed: %s" set-buffer-process-coding-system raw-text-unix make-local-variable smtpmail-read-point :capabilities smtpmail-command-or-throw "HELO %s" delete "" split-string "\r\n" ...] 24)
  smtpmail-via-smtp((#("winkler@gnu.org" 0 16 (fontified t))) #<buffer  smtpmail temp>)
  smtpmail-send-it()
  mail-send()
  call-interactively(mail-send nil nil)

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

>> (make-network-process :name "smtpmail" :buffer (get-buffer-create "foo") :host
>> "foo.bar.com" :service 465)
>> 
>> does it hang?
>
> Yes, this hangs, too. (A backtrace doesn't give anything useful
> beyond the call of make-network-process.)

If that hangs, then something is seriously wrong.  Are you able to
connect to port 465 on foo.bar.com at all with telnet, for instance?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Mon Jul 11 2011 Lars Magne Ingebrigtsen wrote:
> If that hangs, then something is seriously wrong.  Are you able to
> connect to port 465 on foo.bar.com at all with telnet, for
> instance?

$ telnet foo.bar.com 465
Connected to foo.bar.com.
Escape character is '^]'.
220 foo.bar.com ESMTP Postfix


I do not know how to go on from there (I am not quite familiar with
the dialect I am supposed to talk here) but it seems to me that
things work in principle...

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> $ telnet foo.bar.com 465
> Connected to foo.bar.com.
> Escape character is '^]'.
> 220 foo.bar.com ESMTP Postfix

That looks fine.  I just wanted to be sure that the SMTP server
responded normally.

> I do not know how to go on from there (I am not quite familiar with
> the dialect I am supposed to talk here) but it seems to me that
> things work in principle...

The bizarre thing is that this hangs:

(make-network-process :name "smtpmail" :buffer (get-buffer-create "foo") :host "foo.bar.com" :service 465)

But that seems virtually impossible.  `make-network-process' is a simple
C function that just connect to the port in question.  If that hangs,
then something is very wrong with your Emacs installation.  But I don't
know what that could be.

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Mon Jul 11 2011 Lars Magne Ingebrigtsen wrote:
> The bizarre thing is that this hangs:
> 
> (make-network-process :name "smtpmail" :buffer (get-buffer-create "foo") :host
> "foo.bar.com" :service 465)
> 
> But that seems virtually impossible.  `make-network-process' is a simple
> C function that just connect to the port in question.  If that hangs,
> then something is very wrong with your Emacs installation.  But I don't
> know what that could be.

Certainly it goes beyond my knowledge, too. All I can say is that
unfortunately I cannot use much emacs 24 if sending emails is not
possible for me.

Who knows more about such things?

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Certainly it goes beyond my knowledge, too. All I can say is that
> unfortunately I cannot use much emacs 24 if sending emails is not
> possible for me.

The thing that makes it even more weird is that when you switch to the
`plain' connection, then you get an error message from the SMTP server,
so you're obviously able to connect to it then.

So it seems like something that shouldn't be possible.

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Mon Jul 11 2011 Lars Magne Ingebrigtsen wrote:
> "Roland Winkler" <winkler@gnu.org> writes:
> 
> > Certainly it goes beyond my knowledge, too. All I can say is that
> > unfortunately I cannot use much emacs 24 if sending emails is not
> > possible for me.
> 
> The thing that makes it even more weird is that when you switch to the
> `plain' connection, then you get an error message from the SMTP server,
> so you're obviously able to connect to it then.
> 
> So it seems like something that shouldn't be possible.

A brief update:

I was traveling when I first noticed this bug, and I have been
traveling since then. So I do not quite know what kind of internet
connection I have been using and certainly this is an aspect I
cannot investigate.

But I can say that somehow the error messages I get have changed:

make-network-process does not hang anymore, that's good. But I still
cannot send emails. I am surprised that Emacs never asks me for a
username / password for the remote server. Indeed, it seems that
emacs assumes that it can establish a connection to the smtp server
without this. But when emacs passes the "RCPT TO:..." to the smtp
server, the server says

554 <winkler@gnu.org>: Recipient address rejected: Access denied

(no matter what valid email address I use as recipient)

I do not know how the new code is supposed to work here. Emacs 23
had the variables smtpmail-auth-credentials and
smtpmail-starttls-credentials. But these do not exist anymore.
How are these things supposed to work with the new code?
Will this be documented?

I'll try to understand better what the new code is doing. And I can
certainly compare with the code from Emacs 23 that works fine for
me.

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> make-network-process does not hang anymore, that's good. But I still
> cannot send emails. I am surprised that Emacs never asks me for a
> username / password for the remote server. Indeed, it seems that
> emacs assumes that it can establish a connection to the smtp server
> without this. But when emacs passes the "RCPT TO:..." to the smtp
> server, the server says
>
> 554 <winkler@gnu.org>: Recipient address rejected: Access denied
>
> (no matter what valid email address I use as recipient)
>
> I do not know how the new code is supposed to work here. Emacs 23
> had the variables smtpmail-auth-credentials and
> smtpmail-starttls-credentials. But these do not exist anymore.
> How are these things supposed to work with the new code?
> Will this be documented?

Did you try what I suggested?

(defun gnutls-available-p () nil)

and leaving `smtpmail-stream-type' alone?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Wed Jul 13 2011 Lars Magne Ingebrigtsen wrote:
> Did you try what I suggested?
> 
> (defun gnutls-available-p () nil)
> 
> and leaving `smtpmail-stream-type' alone?

Yes. -- Sometimes I loose track of what I have been doing.

My previous email really refers to gnutls-available-p being
redefined as above. In this case emacs never asks for the username /
password. But I get "Recipient address rejected: Access denied"

Side remark: I also noticed that the info page smtpmail still refers
  to the old code with the outdated variables
  smtpmail-auth-credentials and smtpmail-starttls-credentials.

Using the builtin version of gnutls-available-p I get the
"Key usage violation in certificate" with which I started this
thread. Here I can add another detail:

With emacs 23, I need 

(setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))

Otherwise, I get likewise the "Key usage violation in certificate".
This setting has been buried in my .emacs for so long I almost
forgot this. For details, see

http://lists.gnu.org/archive/html/help-gnutls/2009-05/msg00042.html

Unfortunately, there is not too much I can do about the fact that I
need these extra gnutls argument. Anyway, could it be that I would
need to do something similar for the new builtin code?

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Wed Jul 13 2011 Roland Winkler wrote:
> On Wed Jul 13 2011 Lars Magne Ingebrigtsen wrote:
> > Did you try what I suggested?
> > 
> > (defun gnutls-available-p () nil)
[snip]
> With emacs 23, I need 
> 
> (setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))

One more thought:

In a site-wide installation of emacs it is more likely that one or
the other emacs user finds himself in the situation that he needs to
run gnutls with whatever special option that might be more difficult
to achieve with the new builtin gnutls code. So it might be good to
have an option for disabling this builtin code in a cleaner way than
redefining the builtin function gnutls-available-p.

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Fri, 15 Jul 2011 06:16:14 -0500 "Roland Winkler" <winkler@gnu.org> wrote: 

RW> In a site-wide installation of emacs it is more likely that one or
RW> the other emacs user finds himself in the situation that he needs to
RW> run gnutls with whatever special option that might be more difficult
RW> to achieve with the new builtin gnutls code. So it might be good to
RW> have an option for disabling this builtin code in a cleaner way than
RW> redefining the builtin function gnutls-available-p.

I think there should be no such situations; the command-line GnuTLS
tools are insecure and unreliable and should not have to be used.  As
with the priority string option, whatever options users need should get
added.  I see those cases as bugs rather than feature requests.

Again, sorry I haven't looked at any of the GnuTLS or other bugs in
weeks, but I should be back in 10 days or so and will make an effort to
work through the backlog.

Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Using the builtin version of gnutls-available-p I get the
> "Key usage violation in certificate" with which I started this
> thread. Here I can add another detail:
>
> With emacs 23, I need 
>
> (setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))
>
> Otherwise, I get likewise the "Key usage violation in certificate".
> This setting has been buried in my .emacs for so long I almost
> forgot this. For details, see
>
> http://lists.gnu.org/archive/html/help-gnutls/2009-05/msg00042.html

Right, so there needs to be a way to do this with the builtin TLS code,
too.

Ted, do you know what the correct incantation would be?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Wed, 13 Jul 2011 11:06:51 -0500 "Roland Winkler" <winkler@gnu.org> wrote: 

RW> With emacs 23, I need 

RW> (setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))

RW> Otherwise, I get likewise the "Key usage violation in certificate".
RW> This setting has been buried in my .emacs for so long I almost
RW> forgot this. For details, see

RW> http://lists.gnu.org/archive/html/help-gnutls/2009-05/msg00042.html

RW> Unfortunately, there is not too much I can do about the fact that I
RW> need these extra gnutls argument. Anyway, could it be that I would
RW> need to do something similar for the new builtin code?

I'm unable to get online for at least another week so please don't wait
for me on any GnuTLS-related issues.

Regarding this, this is just changing the priority string.  gnutls.el
doesn't have a facility for that but it's pretty easy to define a new
defcustom, it's just a string (see `gnutls-negotiate').  Doing it by
host is slightly more complicated but still not too bad.

If you can wait for me, I'll do this; otherwise Lars or someone else can
make the change.

Thanks
Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Regarding this, this is just changing the priority string.  gnutls.el
> doesn't have a facility for that but it's pretty easy to define a new
> defcustom, it's just a string (see `gnutls-negotiate').

I see.  In this case the priority string would just be "normal:-dhe-rsa"?

> Doing it by host is slightly more complicated but still not too bad.

Hm...  where would this be controlled from?  And don't say auth-source.
:-)

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Fri, 15 Jul 2011 19:13:49 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Regarding this, this is just changing the priority string.  gnutls.el
>> doesn't have a facility for that but it's pretty easy to define a new
>> defcustom, it's just a string (see `gnutls-negotiate').

LMI> I see.  In this case the priority string would just be "normal:-dhe-rsa"?

Yes, the way you have it now (with uppercase) is fine.

>> Doing it by host is slightly more complicated but still not too bad.

LMI> Hm...  where would this be controlled from?  And don't say auth-source. :-)

Let's see if anyone actually needs it and what their use case is.  It
could be an alist you can customize or 'auth-source to invoke
`auth-source-search'.  I think it will be a pretty rare need though, so
don't stay up all night thinking about it.  Horticulture.

Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> If you can wait for me, I'll do this; otherwise Lars or someone else can
> make the change.

I've now made a probably too-simple fix for this.

Roland, could you upgrade your Emacs and say

(setq gnutls-algorithm-priority "normal:-dhe-rsa")

and see whether that fixes the problem?

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Fri Jul 15 2011 Lars Magne Ingebrigtsen wrote:
> Roland, could you upgrade your Emacs and say
> 
> (setq gnutls-algorithm-priority "normal:-dhe-rsa")
> 
> and see whether that fixes the problem?

Similar to disabling gnutls-available-p, this now aborts with the
message

RCPT TO:<winkler@gnu.org>
554 <winkler@gnu.org>: Recipient address rejected: Access denied

But I am surprised that Emacs tries to send the message even though
the smtp server is configured such that it requires a username and
password for sending messages and I do not have yet an .authinfo
entry for the smtp server. It is my understanding that the emacs
code is such that emacs should ask me for username / password if
emacs believes it needs one for the smtp session. In other words, it
appears to me as if emacs and the smtp server do not communicate
properly so that emacs wants to send the message in a way that is
not supported by the smtp server. (I have no such problems with
emacs 23.)

On Fri Jul 15 2011 Ted Zlatanov wrote:
> I think there should be no such situations; the command-line GnuTLS
> tools are insecure and unreliable and should not have to be used.  As
> with the priority string option, whatever options users need should get
> added.  I see those cases as bugs rather than feature requests.

I understand your goal and in the long run it is probably the best
solution. I am merely looking at this from the perspective: if I had
been a regular user running into such a problem after release of
emacs 24, I would have been stuck. The new code is a substantial
change as compared to the old approach. And I do not see a simple
way to predict which other gnutls options might be needed by other
users. So even if the command line gnutls-cli is not perfect by
itself, it would give the user a more forgiving transition period if
with Emacs 24 the old approach remained available as a fallback.

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

> Similar to disabling gnutls-available-p, this now aborts with the
> message
>
> RCPT TO:<winkler@gnu.org>
> 554 <winkler@gnu.org>: Recipient address rejected: Access denied

Is this with all the workarounds (including the `smtpmail-stream-type')
disabled?

What's the SMTP server type?

If you don't have any customisations enabled, I may have fixed this
particular problem i bzr Emacs now.

> I understand your goal and in the long run it is probably the best
> solution. I am merely looking at this from the perspective: if I had
> been a regular user running into such a problem after release of
> emacs 24, I would have been stuck.

Emacs 24 is half a year away, at least.  

> So even if the command line gnutls-cli is not perfect by itself, it
> would give the user a more forgiving transition period if with Emacs
> 24 the old approach remained available as a fallback.

Sure.  But there's no reason why the built-in GnuTLS support shouldn't
be even more flexible than the gnutls-cli support.

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Sun Jul 17 2011 Lars Magne Ingebrigtsen wrote:
> "Roland Winkler" <winkler@gnu.org> writes:
> > RCPT TO:<winkler@gnu.org>
> > 554 <winkler@gnu.org>: Recipient address rejected: Access denied
> 
> Is this with all the workarounds (including the `smtpmail-stream-type')
> disabled?

For my recent attempts to send mail, I have smtpmail-stream-type
bound to nil and no redifinition of gnutls-available-p.

The only customization is

  (setq gnutls-algorithm-priority "normal:-dhe-rsa")

> What's the SMTP server type?

How can I find this out?
(The server is running some flavor of GNU/Linux)

> If you don't have any customisations enabled, I may have fixed this
> particular problem i bzr Emacs now.

Now things have changed, but still no success. Now I get

RCPT TO:<winkler@gnu.org>
530 Must issue a STARTTLS command first

As in my previous email, emacs still does not ask me for the
username and password.

> > So even if the command line gnutls-cli is not perfect by itself, it
> > would give the user a more forgiving transition period if with Emacs
> > 24 the old approach remained available as a fallback.
> 
> Sure.  But there's no reason why the built-in GnuTLS support shouldn't
> be even more flexible than the gnutls-cli support.

I cannot claim I understand these things in more detail. If you feel
confident that you can implement in the new code the same amount of
customizability (or more) that's fine!

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

>> What's the SMTP server type?
>
> How can I find this out?
> (The server is running some flavor of GNU/Linux)

(setq smtpmail-debug-info t)

and then mail me the complete contents of the "*trace ..." buffer after
it fails.

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Roland Winkler]

On Sun Jul 17 2011 Lars Magne Ingebrigtsen wrote:
> "Roland Winkler" <winkler@gnu.org> writes:
> >> What's the SMTP server type?
> >
> > How can I find this out?
> > (The server is running some flavor of GNU/Linux)
> 
> (setq smtpmail-debug-info t)
> 
> and then mail me the complete contents of the "*trace ..." buffer after
> it fails.

I need to apologize once more. Somehow my different attempts to send
emails got screwed up once more. The bottom line is:

Now I can send emails with the latest emacs snapshot I downloaded
yesterday. For this I only use the customization

      (setq gnutls-algorithm-priority "normal:-dhe-rsa")

Emacs has generated the proper entry in ~/.authinfo. (I would prefer
if it used ~/.authinfo.gpg for that, but this is probably a separate
story.)

From the perspective of a user who doesn't know much about smtp, I
agree with Stefan's previous message suggesting that it would be
nice to get rid of the need to have customizations such as

      (setq gnutls-algorithm-priority "normal:-dhe-rsa")

But from my perspective this may go on the wishlist.

Thanks a lot for all your efforts with this!

Roland

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Sun, 17 Jul 2011 21:46:04 -0500 "Roland Winkler" <winkler@gnu.org> wrote: 

RW> From the perspective of a user who doesn't know much about smtp, I
RW> agree with Stefan's previous message suggesting that it would be
RW> nice to get rid of the need to have customizations such as

RW>       (setq gnutls-algorithm-priority "normal:-dhe-rsa")

RW> But from my perspective this may go on the wishlist.

I think we're saying that if the priority string generates this error:

gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

we should at least tell the user "hey, maybe 

(setq gnutls-algorithm-priority "normal:-dhe-rsa"

would work for you.  Do you want to try it?"

I don't think it should be tried automatically.  That's convenient but
insecure.  The priority string above basically disables security.

If you agree about the prompting or have a better suggestion we can
unarchive this bug.

Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate
> has been detected.
>
> we should at least tell the user "hey, maybe 
>
> (setq gnutls-algorithm-priority "normal:-dhe-rsa"
>
> would work for you.  Do you want to try it?"
>
> I don't think it should be tried automatically.  That's convenient but
> insecure.  The priority string above basically disables security.

Oh, I thought it just disabled the dhe-rsa-algorithm?  Which would then
allow gnutls to fall back on different algos?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Wed, 25 Jan 2012 20:39:56 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate
>> has been detected.
>> 
>> we should at least tell the user "hey, maybe 
>> 
>> (setq gnutls-algorithm-priority "normal:-dhe-rsa"
>> 
>> would work for you.  Do you want to try it?"
>> 
>> I don't think it should be tried automatically.  That's convenient but
>> insecure.  The priority string above basically disables security.

LI> Oh, I thought it just disabled the dhe-rsa-algorithm?  Which would then
LI> allow gnutls to fall back on different algos?

From Nikos' reply recommending -dhe-rsa:

"This certificate restricts its usage to key encipherment. For TLS this
is restricted to only the RSA key exchange. By misconfiguration however
the server allows you to connect with a ciphersuite that violates this
usage and that's why gnutls-cli fails to connect."

I may be misunderstanding the intent, but I thought globally you're
saying you'll allow restricted certificates.  I'm not sure that's ideal
and I think it is insecure, but I'm not so sure anymore after thinking
about it more carefully.

Either way it seems that `gnutls-algorithm-priority' will have to be one
of those string-or-alist-or-function variables, so you can disable
security altogether for specific hosts that need it.  I can add that
support if you think it's reasonable.

Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> "This certificate restricts its usage to key encipherment. For TLS this
> is restricted to only the RSA key exchange. By misconfiguration however
> the server allows you to connect with a ciphersuite that violates this
> usage and that's why gnutls-cli fails to connect."

I'm afraid I don't understand what this is saying at all.  :-)

> I may be misunderstanding the intent, but I thought globally you're
> saying you'll allow restricted certificates.  I'm not sure that's ideal
> and I think it is insecure, but I'm not so sure anymore after thinking
> about it more carefully.
>
> Either way it seems that `gnutls-algorithm-priority' will have to be one
> of those string-or-alist-or-function variables, so you can disable
> security altogether for specific hosts that need it.  I can add that
> support if you think it's reasonable.

I think the nice way to handle this would be to prompt the user here.
With something like "The server provides buggy dhe-rsa credentials;
connect anyway?" or something, which would result in "-dhe-rsa" being
added to the variable.

But as you point out, it should be on a per-host basis, probably...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Ted Zlatanov]

On Wed, 25 Jan 2012 23:35:35 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

>> Either way it seems that `gnutls-algorithm-priority' will have to be one
>> of those string-or-alist-or-function variables, so you can disable
>> security altogether for specific hosts that need it.  I can add that
>> support if you think it's reasonable.

LI> I think the nice way to handle this would be to prompt the user here.
LI> With something like "The server provides buggy dhe-rsa credentials;
LI> connect anyway?" or something, which would result in "-dhe-rsa" being
LI> added to the variable.

LI> But as you point out, it should be on a per-host basis, probably...

OK, so by default it's a string and it works OK for most people.

When we get the key exception Roland had, we ask the user and then
convert `gnutls-algorithm-priority' to 
'((t old-value) (current-host "normal:-dhe-rsa")) or we create a new
entry if it's already an alist.

We also support a function, which gets the hostname as a parameter and
returns a string.

Cool?

Ted

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> When we get the key exception Roland had, we ask the user and then
> convert `gnutls-algorithm-priority' to 
> '((t old-value) (current-host "normal:-dhe-rsa")) or we create a new
> entry if it's already an alist.
>
> We also support a function, which gets the hostname as a parameter and
> returns a string.
>
> Cool?

Yes, that sounds nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@gnu.org> writes:

>>From the perspective of a user who doesn't know much about smtp, I
> agree with Stefan's previous message suggesting that it would be
> nice to get rid of the need to have customizations such as
>
>       (setq gnutls-algorithm-priority "normal:-dhe-rsa")
>
> But from my perspective this may go on the wishlist.
>
> Thanks a lot for all your efforts with this!

I think this can be closed now.  The problem was most likely a buggy TLS
installation on the server, because gnutls was unable to negotiate an
encryption algorithm to use.  

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

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Stefan Monnier]

> (setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))

I presume that users of MUAs like Outlook don't need to go through so
much trouble, so it should be possible for Emacs to similarly find the
magic incantation without the user having to get into such details.


        Stefan

bug#9017: 24.0.50; gnutls.c: [0] (Emacs) fatal error: Key usage violation in certificate has been detected.

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (setq starttls-extra-arguments '("--priority" "normal:-dhe-rsa"))
>
> I presume that users of MUAs like Outlook don't need to go through so
> much trouble, so it should be possible for Emacs to similarly find the
> magic incantation without the user having to get into such details.

You'd hope.  But when researching the error message this user got, I
found the same error message from a Thunderbird user, I think it was.
The problem is basically a somewhat invalid certificate being served up
by the server.  The recommended way to fix that is to fix the server.

But, yes, I hope we can do better.  If one cipher (or whatever this is
:-) fails, why not try the other ones automatically instead of failing
completely?  You'd imagine that would be doable...

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