Re: [exim] TLS client disconnected cleanly (rejected our ce…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] TLS client disconnected cleanly (rejected our certificate? ) - intermediate ssl certificate problem?
Arkadiusz Miskiewicz wrote:
> On Friday 27 of May 2011, W B Hacker wrote:
>> W B Hacker wrote:
>>
>> Disregard last - Brain Fart - tested his posting address.
>>
>> Here is a run at postmaster@???
>>
>> No cert complaint not even one mentioned, but blocked for lack of smtp
>> auth.
>
> Hm, openssl s_client was able to verify certificates correctly, saw proper
> chain etc (Verify return code: 0 (ok)), so looks like exim is doing correct
> job after all.


Good news ...
>
> So far got few reports from people using thunderbird 3.1.10 under windows
> about certs not being accepted. Could be that the bug is in thunderbird. Doing
> some testing with it.


Windows is not cooperating? Go figure...

Have we all been chasing non-Exim winbuggery?

;-)

Mostly SeaMonkey here. Not 100% same MUA code as T-bird. At all.

But it always JFW on *BSD, Linux, Mac.

Have noted that Firefox 4 and even late-edition of the last of 3.X have
gotten progressively pickier about our self-signed certs (for webmail).

Basically w/r NOT allowing just-anyone to make an exception 'permanent'
so presume T-bird doing much the same. (Depends on OTHER settings).

Doesn't find fault with the certs - just no built-in CA to vet it with.

If a person needs to grant a CA exemption?

Actual logs:

====

Initial connect:
========

2011-05-27 06:20:39 [21219] SMTP connection from [61.10.57.220]:50810
I=[203.194.153.81]:587 (TCP/IP connection count = 1)

2011-05-27 06:20:40 [23591] TLS error on connection from
[61.10.57.220]:50810 I=[203.194.153.81]:587 (SSL_accept):
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate

2011-05-27 06:20:40 [23591] TLS client disconnected cleanly (rejected
our certificate?)

2011-05-27 06:21:16 [21219] SMTP connection from [61.10.57.220]:50811
I=[203.194.153.81]:587 (TCP/IP connection count = 1)

====

Retry:

Same caller. Note IP and TOD. A cert exception was being granted by the
user while above was going down, was ready for use next retry:

========

2011-05-27 06:21:16 [21219] SMTP connection from [61.10.57.220]:50811
I=[203.194.153.81]:587 (TCP/IP connection count = 1)

2011-05-27 06:21:16 [9222] H=cm61-10-57-220.hkcable.com.hk
(loki0.triligon.to) [61.10.57.220]:50811 I=[203.194.153.81]:587 Warning:
H1 cm61-10-57-220.hkcable.com.hk 61.10.57.220 submission client
arriving on port 587 with smtp

2011-05-27 06:21:16 [9222] H=cm61-10-57-220.hkcable.com.hk
(loki0.triligon.to) [61.10.57.220]:50811 I=[203.194.153.81]:587 Warning:
R0 cm61-10-57-220.hkcable.com.hk 61.10.57.220 is authenticated using
esmtpsa

2011-05-27 06:21:16 [9222] R1 cm61-10-57-220.hkcable.com.hk
61.10.57.220 is one of ours using esmtpsa

=========

>
>> Bit unusual to require that of 'postmaster@', but I'll presume a bespoke
>> relay-only box, or simply still under construction?
>
> Not unusual for submission box (rfc4409).
>
>>> Bill Hacker


So long as all-hands are in a net you control, port 25 is fine.

Soon as someone moves office or house, or travels and finds traffic
'from any to any port 25' blocked outright or intercepted by/to the
uplink provider's OWN MTA ?

... 587 will look a great deal better...

It is very rarely interfered with.

Bill

韓家標