@StuartHickinbottom explained what I was doing wrong: using libgnutls-28.dll when Emacs 25.1 requires the newer and incompatible libgnutls-30.dll. Then it was a matter of finding binaries of libgnutls-30.dll and other required libraries. Thankfully Phillip Lord has compiled Windows versions of all the GnuTLS libraries and dependencies and many other ...
Add /private/etc/ssl/cert.pem to gnutls-trustfiles:
Customize variable: gnutls-trustfiles
Select the last [INS]
Bundle filename: /private/etc/ssl/cert.pem
Select [ Apply and Save ]
I found this reddit comment, which states that the problem is Emacs built-in TLS doesn't reject bad certificates. It proposes using external TLS like this:
(if (fboundp 'gnutls-available-p)
NOTE: if you still have issues trying to connect to marmalde repo, it seems to be a different problem. See this github issue.
To solve this issue it seems sufficient to:
Set gnutls-verify-error to t, and
Add an appropriate trusted root certificate file to gnutls-trustfiles - the default setting for that list does not include any existing files on OS X and it doesn't seem to default to using the system keychain.
This can be done, for example, by installing libressl from homebrew ...
As jabber.el started using the GnuTLS facility of Emacs before the variable gnutls-verify-error existed, it uses its own variable jabber-invalid-certificate-servers. That variable contains a list of all servers for which certificate errors should be ignored. Try this:
(setq jabber-invalid-certificate-servers '("chat.deshackra.com"))
When encrypting, GPG uses the recipient's public key (so only she can decrypt it, with her private key). Your own keys are not used (neither private nor public). You private key is only used either to sign what you send, or to decrypt what ou receive.
Your question is similar to the old one accessing MELPA/ELPA sites, also https - so there are two possible solutions to solve that:
Upgrade to emacs version 26.3, this is solved there; - but seems to need more work as revealed by @npostavs.
If you still need version 26.2, then add to your custom file the following:
This problem was solved by forcing emacs to use https instead of http. For some reason, emacs is using http as default instead of https.
Steps to solve:
(customize-variable RET package-archives)
changed http to https in url fields
I wonder why emacs would use http as a default?...
I had the same problem. Could send mail from home but not at university. I struggle with it for days. I was already using but I was using the port 587. Then changing to port 465 did the job.
So may be you only have to add
(setq smtpmail-stream-type 'ssl)
Make sure you don't have any port number specified in your .authinfo file, it might override the ...
I can't mark a comment as an answer, so I will copy the comment of phils to mark it as a solution.
"I believe you want https for both gnu and melpa, and furthermore that marmalade may no longer be active (I didn't think it was still running, and while the domain is valid, it seemingly doesn't have a current certificate). You would rarely want to prefer ...
Emacs package.el supports local package repo.
So here is the solution,
Create a local repo from your installed packages using https://github.com/redguardtoo/elpa-mirror
Add local repo path to package-archives, then start up Emacs as usual.
(setq package-archives '(("myelpa" . "~/myelpa/")))
I solved this by setting the variable gnutls-algorithm-priority to TLS-1.2.
(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.2").
It's because on Windows or Windows Subsystem Linux (WSL) the local gnutls-utils may not support TLS1.3.
When in doubt, simplify. Start your Emacs with emacs -Q to disable initialization. Then in the *scratch* buffer, evaluate the following lines by hitting Ctrl+j after each lisp line. Afterwards your *scratch* buffer will look like:
Then do Meta+x list-packages. This will ...
After much digging, I believe a common cause of this is likely a combination of two things:
elpa.gnu.org is misconfigured, sending its own certificate in duplicate before the issuer certificate - this counts as an out-of-order certificate problem. This can be confirmed using gnutls-cli or openssl s_client. I have notified the maintainer.
A lack of ...
I tried gnutls-cli hostname -p 9001 to check if there actually was a problem with the cert (and not just my Emacs 25) and it turns out the certificate was expired. So it seems Emacs 24 didn't care about expiry (nor did the weechat android app). Redoing http://www.weechat.org/files/doc/stable/weechat_user.en.html#relay_ssl (and updating my ~/.emacs.d/weechat-...
You have hopefully figured this out by now but I think you need (setq smtpmail-stream-type 'starttls). You've specified TLS directly which won't work if the service expects unencrypted connections at first with starttls support.
On Windows 10, I solved the problem by starting Emacs with the admin prompt (seems that admin rights matter). Also, you should check on whether gnutls is properly installed, following the instructions here: https://stackoverflow.com/questions/36950871/failed-to-download-melpa-archive
Thanks to comments posted by legoscia, it is functioning!
Mainly, I had to remove tls-program definition.
(setq tls-program '("c:/Progra~2/Git/bin/openssl.exe s_client -connect %h:%p -no_ssl2 -ign_eof -CAfile c:/full/path/to/ca-bundle.crt"))
And make sure the OpenSSL DLL is present in the same directory as Emacs.
It is also noted that some OpenSSL ...
You do not need to use a full Emacs email client like Gnus or mu4e (although I recommend it); message-mode should be sufficient to compose and send email, and to encrypt or sign outgoing messages. I have not used smtpmail before. My setup relies on an external smtp client (msmtp), but this should not be necessary.
To compose emails, use message-mail. To ...