On Thu, 23 Feb 2017, KT Walrus wrote:
It's on my to-do list, but I think you can use dehydrated in signing
mode.
--signcsr (-s) path/to/csr.pem Sign a given CSR, output CRT on stdout
(advanced usage)
In this way, you can reuse private key, as well as making it more
secure by
> On Feb 20, 2017, at 4:01 PM, Joseph Tam wrote:
>
> yacinechaou...@yahoo.com writes:
>
>> Interesting. Is there any particular benefit in having only one file
>> for both certificate and private key ? I find that putting private key
>> in a separate file feels more
On 17.02.17 22:57 Bastian Sebode wrote:
> Finally I found the issue! :-) But I still have no idea why the
> problem happens with Thunderbird.
>
> I used dehydrated to fetch the certificates from Let's Encrypt and
> as I said, it works for most clients pretty well. (Tried: Mulberry,
> Claws Mail,
On 19 Feb 2017, at 00:00, Michael A. Peters wrote:
> That's one of the reasons I don't like Let's Encrypt, with one year certs it
> is easier to look at the certs and see what is going to expire in the coming
> month needing a new private key.
Since renewal is entirely
yacinechaou...@yahoo.com writes:
Interesting. Is there any particular benefit in having only one file
for both certificate and private key ? I find that putting private key
in a separate file feels more secure.
It's convenient to have key and cert in one place if you don't need
the
Hello, I have fixed my problem.
I had used the wrong cert-file.
ssl_cert = Bast, the way I understand it is that Let's Encrypt is not a Root Certificate
> Authority, it's an intermediate. The root CA of Let's Encrypt is "
> DST_Root_CA_X3.crt", you should find it in /etc/ssl/certs/. I have
>
Hello, I have fixed my problem.
I had used the wrong cert-file.
ssl_cert = Bast, the way I understand it is that Let's Encrypt is not a Root Certificate
> Authority, it's an intermediate. The root CA of Let's Encrypt is "
> DST_Root_CA_X3.crt", you should find it in /etc/ssl/certs/. I have
>
Bast, the way I understand it is that Let's Encrypt is not a Root Certificate
Authority, it's an intermediate. The root CA of Let's Encrypt is "
DST_Root_CA_X3.crt", you should find it in /etc/ssl/certs/. I have sucessfully
installed a Let's Encrypt certificate on a debian machine by Octobre
I have try LE on October 2016 and use Icedove 45.6.0. I can't found any
certificate of LE in certificate manager -> authorities
On 20.02.2017 15:43, chaouche yacine wrote:
> Hello Basti. Maybe you tried LE too early when it was not universally
> accepted as a trusted CA ?
>
>
> On
On 02/20/2017 01:32 AM, chaouche yacine wrote:
What is the motivation behind using a new pair of keys and CSR ?
Every now and then, a bug in the OpenSSL API is found that leaked the
private key under certain conditions.
By replacing the private key once a year with a new one, you are at
Hello Basti. Maybe you tried LE too early when it was not universally accepted
as a trusted CA ?
On Monday, February 20, 2017 2:22 PM, basti wrote:
Hello,
I had the same problem. LE is not in the CA list.
Best Regards,
On 17.02.2017 17:58, Bastian Sebode
Hello,
I had the same problem. LE is not in the CA list.
Best Regards,
On 17.02.2017 17:58, Bastian Sebode wrote:
> Hello Folks,
>
> my StartCom SSL-Certificate expires soon and so I wanted to switch to
> Let's Encrypt Certificates instead. Unfortunatelly Thunderbird seems not
> to like it,
On 2017-02-19, KT Walrus wrote:
>> That's one of the reasons I don't like Let's Encrypt, with one year
>> certs it is easier to look at the certs and see what is going to expire
>> in the coming month needing a new private key.
>
> I use dehydrated (with Cloudflare DNS
What is the motivation behind using a new pair of keys and CSR ?
On 02/19/2017 08:39 PM, Michael A. Peters wrote:
> Every time I change the private key -
>
> A) I have to make a TLSA record for the new key
You're actually expected to pin the CA in your TLSA record, not your own key.
On 02/19/2017 05:39 AM, KT Walrus wrote:
That's one of the reasons I don't like Let's Encrypt, with one year certs it is
easier to look at the certs and see what is going to expire in the coming month
needing a new private key.
I use dehydrated (with Cloudflare DNS challenges) and as far as
> That's one of the reasons I don't like Let's Encrypt, with one year certs it
> is easier to look at the certs and see what is going to expire in the coming
> month needing a new private key.
I use dehydrated (with Cloudflare DNS challenges) and as far as I know, it
seems to generate a new
On 02/18/2017 10:24 PM, Robert L Mathews wrote:
On 2/17/17 1:38 PM, chaouche yacine wrote:
Seems wrong to me too, Robert. If you put your private key inside
your certificate, won't it be sent to the client along with it ?
No; any SSL software that uses the file will extract the parts it
On 2/17/17 1:38 PM, chaouche yacine wrote:
> Seems wrong to me too, Robert. If you put your private key inside
> your certificate, won't it be sent to the client along with it ?
No; any SSL software that uses the file will extract the parts it needs
from it and convert them to its internal
On 2017-02-17 (11:28 MST), Robert L Mathews wrote:
>
> ssl_cert = ssl_key = You're also manually specifying these non-default parameters:
>
> ssl_cipher_list = ...
> ssl_prefer_server_ciphers = yes
> ssl_protocols = !SSLv2 !SSLv3
>
> For testing, I would simplify. Does
On 2017-02-17 (09:58 MST), Bastian Sebode wrote:
>
> Weirdly my friend uses the same Dovecot Version with Let's Encrypt on
> his Server and it works with Thunderbird without any flaws. Mine fails
> the same way in his Thunderbird and also in a fresh installation.
Interesting. Is there any particular benefit in having only one file for both
certificate and private key ? I find that putting private key in a separate
file feels more secure.
Bastian, how could two identical certificates be processed differently by
Thunderbid ? how did you check the
On 2/17/2017 2:38 PM, chaouche yacine wrote:
> Seems wrong to me too, Robert. If you put your private key inside your
> certificate, won't it be sent to the client along with it ?
The private key should not be sent to the connecting client, even if it
is contained in the same place as the
Hey.
Thanks again for your help. I took the "dovecot -n" while the StartSSL
Certificate was active, so the chain.pem was correct.
Finally I found the issue! :-) But I still have no idea why the problem
happens with Thunderbird.
I used dehydrated to fetch the certificates from Let's Encrypt and
On 2017-02-17 22:38, chaouche yacine wrote:
Seems wrong to me too, Robert. If you put your private key inside your
certificate, won't it be sent to the client along with it ?
This is one way of supplying cert + key to a daemon and no, the key is
not sent to the client.
While it is normaly
Seems wrong to me too, Robert. If you put your private key inside your
certificate, won't it be sent to the client along with it ?
Bastian, are you using an old version of thunderbird ? googling for "SSL alert
number 42" gave me two results indicating a bug in thunderbird versions 31,32
and
Usually with LE, the filename is fullchain.pem, not chain.pem.
Can you please doublecheck this?
Also, try
openssl s_client -connect hostname:143 -starttls imap
Aki
> On February 17, 2017 at 10:31 PM Bastian Sebode
> wrote:
>
>
> Hey Robert,
>
> thanks for your
On 2017.02.17. 22:31, Bastian Sebode wrote:
Hey Robert,
thanks for your reply.
Am 17.02.2017 um 19:28 schrieb Robert L Mathews:
Looking at your dovecot -n, you're using two different files here:
ssl_cert =
Are You sure, chain.pem contains your cert + immediate? By default
certbot in
Hey Robert,
thanks for your reply.
Am 17.02.2017 um 19:28 schrieb Robert L Mathews:
> Looking at your dovecot -n, you're using two different files here:
>
> ssl_cert = ssl_key =
> Are you sure these two files match, and contain the right things in the
> right order?
>
Yes, unfortunately I'm
On 2/17/17 8:58 AM, Bastian Sebode wrote:
> I uploaded two Wireshark tracefiles, further logs and dovecot -n
Looking at your dovecot -n, you're using two different files here:
ssl_cert = http://www.tigertech.net/
30 matches
Mail list logo