Charles Marcus wrote:
2014-04-18T15:54:07-04:00 dinkumthinkum dovecot: imap-login:
Disconnected (no auth attempts in 0 secs): user=<>, TLS handshaking:
SSL_accept() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3
alert bad certificate: SSL alert number 42, rip=99.14.24.224, lport=143
Am 18.04.2014 22:12, schrieb Charles Marcus:
> Ahh... I'm sure we have some older clients that are still configured to use a
> different hostname...
>
> So, if the new certs are for mail.example.com, and a client tries to connect
> using a different hostname, like
> imap.example.com, would tha
You could try a newer Dovecot from wheezy-backports. Your command works in my
Dovecot 2.2.12.
--
View this message in context:
http://dovecot.2317879.n4.nabble.com/Hash-Verification-with-doveadm-tp47571p47572.html
Sent from the Dovecot mailing list archive at Nabble.com.
Hello!
I have a problem with the doveadm tool. I’m trying to verify a hash from my
MySQL-Db with the following command:
doveadm pw -p '123' -t
'{SHA512-CRYPT}$6$e3TLkiahfHFv29/J$8etBEtmbh06B72kc1TpetT/k8aHkQrJAPQVpTGDYuzyHZX4MwU2PeL2cIupNEoUUGt6SLB0N7xNqbbqp/5OZo.'
I'm expecting that it says v
On 4/18/2014 4:41 PM, Markus Schönhaber
wrote:
The errors indicate that a client didn't like your certificate for
some reason. One of the possible reasons surely is a CN in the
certificate that doesn't match the name of the server the client
thinks he's connecting to. So the answer to your que
18.04.2014 22:12, Charles Marcus:
> On 4/18/2014 3:57 PM, Charles Marcus wrote:
>> Everything seems to be working, BUT... I'm now seeing some of these
>> errors, that were not showing up in the logs before:
>>
>> 2014-04-18T15:42:24-04:00 dinkumthinkum dovecot: imap-login:
>> Disconnected (no a
Il 18/04/2014 22:08, Charles Marcus ha scritto:
On 4/18/2014 3:32 PM, Alessandro Menti wrote:
2) open /etc/ssl/ourNewCerts/mail.ourdomain.com.crt and, at the end of
the file, paste the contents of /etc/ssl/ourNewCerts
/RapidSSL_Intermediate.crt; in the end, /etc/ssl/ourNewCerts
/mail.o
On 4/18/2014 3:57 PM, Charles Marcus wrote:
Everything seems to be working, BUT... I'm now seeing some of these
errors, that were not showing up in the logs before:
2014-04-18T15:42:24-04:00 dinkumthinkum dovecot: imap-login:
Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read()
On 4/18/2014 3:32 PM, Alessandro Menti wrote:
2) open /etc/ssl/ourNewCerts/mail.ourdomain.com.crt and, at the end of
the file, paste the contents of /etc/ssl/ourNewCerts
/RapidSSL_Intermediate.crt; in the end, /etc/ssl/ourNewCerts
/mail.ourdomain.com.crt should contain the certificate f
Thanks Markus and Oscar...
On 4/18/2014 3:29 PM, Markus Schönhaber
wrote:
Aside from the missing indirection (use ... = before) the documentation indicates that ssl_ca is only used for
client certificate verification and has nothing to do with the
certificate chain of your server certificate.
Il 18/04/2014 19:57, Charles Marcus ha scritto:
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed
fiasco, the boss finally agreed to let me buy some real certs...
Until now, we've been using self-signed certs with the following dovecot
config:
ssl = required
ssl_cert
18.04.2014 19:57, Charles Marcus:
> Ok, been wanting to do this for a while, and I after the Heartbleed
> fiasco, the boss finally agreed to let me buy some real certs...
>
> Until now, we've been using self-signed certs with the following dovecot
> config:
>
> ssl = required
> ssl_cert = ssl
On 18/04/2014 1:57 PM, Charles Marcus wrote:
But my current config doesn't have the _file for the variable names,
and the wiki doesn't use them, so I'm planning on setting these to:
ssl = required
ssl_cert = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt
ssl_key = /etc/ssl/ourNewCerts/mail.ourd
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed
fiasco, the boss finally agreed to let me buy some real certs...
Until now, we've been using self-signed certs with the following dovecot
config:
ssl = required
ssl_cert = Now, I've created new keys/certs and the CS
Hello,
Still busy with details...
Considering, as in my previous example, a password_query returning '!' or NULL
for the "nologin" column, depending on an account's status (suspended or not).
Let's consider a suspended user "some.user".
In the case of a successful authentication, one has:
15 matches
Mail list logo