dovecot 2.3.x, ECC and wildcard certificates, any issues
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
I don't know how to get both RSA and ECC cert from letsencrypt.
Aki
On 30 July 2018 at 20:43 David Mehler dave.mehler@gmail.com wrote:
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote:
Hello,
Does dovecot 2.3.x have any issues recognizing or using certificates that are ECC and wildcard? I'm trying to switch my letsencrypt implementation from acme-client which does not support either of those capabilities to acme.sh which does. Since then external clients checking their email has not worked. A manual telnet to mail.example.com 993 gives a connected message but then nothing no greeting or capabilities.
The certificate is for example.com with an alt name of *.example.com if that's not right let me know, i'm not sure about that one, connecting to the web sites of these pages seems noticeably slower, I'm wondering if both of these issues aren't key related?
Thanks. Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
FWIW, it’s relatively straightforward to do this with my Perl ACME implementation, Net::ACME2.
You’ll get your first certificate order using one key, then request another certificate with the other key.
-FG
On Jul 30, 2018, at 1:49 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:
I don't know how to get both RSA and ECC cert from letsencrypt.
Aki
On 30 July 2018 at 20:43 David Mehler dave.mehler@gmail.com wrote:
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
> On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com wrote: > > > Hello, > > Does dovecot 2.3.x have any issues recognizing or using certificates > that are ECC and wildcard? I'm trying to switch my letsencrypt > implementation from acme-client which does not support either of > those > capabilities to acme.sh which does. Since then external clients > checking their email has not worked. A manual telnet to > mail.example.com 993 gives a connected message but then nothing no > greeting or capabilities. > > The certificate is for example.com with an alt name of *.example.com > if that's not right let me know, i'm not sure about that one, > connecting to the web sites of these pages seems noticeably slower, > I'm wondering if both of these issues aren't key related? > > Thanks. > Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
Hello,
I have discovered what I believe is the issue after hearing back from Aquamail. And that is that android 7 which I'm running 7.0 that is, only supports up to the p256 ecc curve. This brings up a question to users of letsencrypt, when you revoke a certificate does it take it out on the usage as well? I've got one domain that says i've issued to many certificates for it and no more can be issued, thought I was using the staging server. I'd like to get those certs off the letsencrypt servers so I can make a new one using the p256 curve. Does anyone know if this is doable? Using acme.sh I tried --revoke which revoked one cert but letsencrypt still would not let me issue another.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
I don't know how to get both RSA and ECC cert from letsencrypt.
Aki
On 30 July 2018 at 20:43 David Mehler dave.mehler@gmail.com wrote:
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
> On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com > wrote: > > > Hello, > > Does dovecot 2.3.x have any issues recognizing or using > certificates > that are ECC and wildcard? I'm trying to switch my letsencrypt > implementation from acme-client which does not support either of > those > capabilities to acme.sh which does. Since then external clients > checking their email has not worked. A manual telnet to > mail.example.com 993 gives a connected message but then nothing no > greeting or capabilities. > > The certificate is for example.com with an alt name of > *.example.com > if that's not right let me know, i'm not sure about that one, > connecting to the web sites of these pages seems noticeably > slower, > I'm wondering if both of these issues aren't key related? > > Thanks. > Dave.
These both should be fine.
Port 993 is TLS encrypted, you should use openssl s_client -connect server:993
Aki
Revocation doesn’t remove the certificates; it just marks them as invalid when a TLS client bothers to check.
-FG
On Jul 30, 2018, at 6:45 PM, David Mehler dave.mehler@gmail.com wrote:
Hello,
I have discovered what I believe is the issue after hearing back from Aquamail. And that is that android 7 which I'm running 7.0 that is, only supports up to the p256 ecc curve. This brings up a question to users of letsencrypt, when you revoke a certificate does it take it out on the usage as well? I've got one domain that says i've issued to many certificates for it and no more can be issued, thought I was using the staging server. I'd like to get those certs off the letsencrypt servers so I can make a new one using the p256 curve. Does anyone know if this is doable? Using acme.sh I tried --revoke which revoked one cert but letsencrypt still would not let me issue another.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
I don't know how to get both RSA and ECC cert from letsencrypt.
Aki
On 30 July 2018 at 20:43 David Mehler dave.mehler@gmail.com wrote:
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote: > >> On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com >> wrote: >> >> >> Hello, >> >> Does dovecot 2.3.x have any issues recognizing or using >> certificates >> that are ECC and wildcard? I'm trying to switch my letsencrypt >> implementation from acme-client which does not support either of >> those >> capabilities to acme.sh which does. Since then external clients >> checking their email has not worked. A manual telnet to >> mail.example.com 993 gives a connected message but then nothing no >> greeting or capabilities. >> >> The certificate is for example.com with an alt name of >> *.example.com >> if that's not right let me know, i'm not sure about that one, >> connecting to the web sites of these pages seems noticeably >> slower, >> I'm wondering if both of these issues aren't key related? >> >> Thanks. >> Dave. > > These both should be fine. > > Port 993 is TLS encrypted, you should use openssl s_client -connect > server:993 > > Aki >
That is one of the reasons I do not bother since long with public CAs but rather deploy my own, including own OSCP responder.
Which has of course has some drawbacks like redundancy, resilience, bandwidth provision, geographical spread, implementing CA security standards and CA trust in clients. Latter though could be easily overcome if browser and email clients were to support DNSSEC/DANE validation.
It may not help you in the short term now but perhaps something to consider long term for the benefit of controlling the certificate handling/signing, depending on the CA scale.
Hello,
I have discovered what I believe is the issue after hearing back from Aquamail. And that is that android 7 which I'm running 7.0 that is, only supports up to the p256 ecc curve. This brings up a question to users of letsencrypt, when you revoke a certificate does it take it out on the usage as well? I've got one domain that says i've issued to many certificates for it and no more can be issued, thought I was using the staging server. I'd like to get those certs off the letsencrypt servers so I can make a new one using the p256 curve. Does anyone know if this is doable? Using acme.sh I tried --revoke which revoked one cert but letsencrypt still would not let me issue another.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
I don't know how to get both RSA and ECC cert from letsencrypt.
Aki
On 30 July 2018 at 20:43 David Mehler dave.mehler@gmail.com wrote:
Hello,
What acme implementation do you use for your letsencrypt certificates? If it's acme.sh how do you get both rsa and ecc certificates? What configuration options are you using in your configuration of services to allow access to both rsa and ecc?
Thanks. Dave.
On 7/30/18, David Mehler dave.mehler@gmail.com wrote:
Hello,
The client in question is the latest version of AquaMail running on android.
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote:
You should, in practice, enable both. This gives best client compability. It is possible you have clients that cannot understand ECC certificates? You can use ssl_alt_cert to provide RSA cert too.
Aki
On 30 July 2018 at 20:05 David Mehler dave.mehler@gmail.com wrote:
Hi,
Thanks, good news is that worked. Bad news is it all looks good which means I do not know hwhy my remote clients can't get their email, looked like from the logs it was that.
Would 143 be better or 993 for the external clients?
Thanks. Dave.
On 7/30/18, Aki Tuomi aki.tuomi@dovecot.fi wrote: >> On 30 July 2018 at 19:16 David Mehler dave.mehler@gmail.com >> wrote: >> >> >> Hello, >> >> Does dovecot 2.3.x have any issues recognizing or using >> certificates >> that are ECC and wildcard? I'm trying to switch my letsencrypt >> implementation from acme-client which does not support either of >> those >> capabilities to acme.sh which does. Since then external clients >> checking their email has not worked. A manual telnet to >> mail.example.com 993 gives a connected message but then nothing no >> greeting or capabilities. >> >> The certificate is for example.com with an alt name of >> *.example.com >> if that's not right let me know, i'm not sure about that one, >> connecting to the web sites of these pages seems noticeably >> slower, >> I'm wondering if both of these issues aren't key related? >> >> Thanks. >> Dave. > These both should be fine. > > Port 993 is TLS encrypted, you should use openssl s_client -connect > server:993 > > Aki >
On 2018-07-30 19:45, ѽ҉ᶬḳ℠ wrote:
That is one of the reasons I do not bother since long with public CAs but rather deploy my own, including own OSCP responder.
May I ask, how you create a CA which is valid for clients without them having to install your root cert?
Cheers, K. C.
-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
That is one of the reasons I do not bother since long with public CAs but rather deploy my own, including own OSCP responder. May I ask, how you create a CA which is valid for clients without them having to install your root cert?
and CA trust in clients. Latter though could be easily overcome if browser and email clients were to support DNSSEC/DANE validation.
That is where DANE/TLSA comes in but it requires DNSSEC/DANE validation in the client and of course DNSSEC and TLSA records in the domain's DNS. Notwithstanding that the upstream DNS resolvers utilized by clients need to support DNSSEC queries/answers as well.
Whatever the reasons for lacking such validation support in most of the clients (incl. web browsers) one speculative is that it would kill commercial CAs (as such Let's Encrypt is one too through their sponsors), or at least has the potential to diminish their business (model).
Suppose we are not hijacking this thread furthermore and avoid earning a discontent eventually ... ;)
participants (5)
-
Aki Tuomi
-
David Mehler
-
Felipe Gasper
-
Helmut K. C. Tessarek
-
ѽ҉ᶬḳ℠