I get good results from using openssl s_server -www
the resulting listener not only lets you check the certs with a browser, but
gives some useful info on what was negotiated if the connection succeeded.
On 23 May 2011 12:22, W B Hacker <wbh@???> wrote:
> Graeme Fowler wrote:
>
>> On Mon, 2011-05-23 at 10:52 +0200, Arkadiusz Miskiewicz wrote:
>>
>>> The question is why "alert bad certificate" comes up if everything looks
>>> fine,
>>> all intermediate certs are provided etc?
>>>
>>
>> Your client *should* provide the reason. If not, connect using the
>> OpenSSL s_client to determine why:
>>
>> openssl s_client -connect $your_ip:$your port
>>
>> See if that throws an error. It may not, but it will provide lots of
>> debug to let you see if all the chained certs are installed correctly.
>>
>> Graeme
>>
>>
>>
> 'nuther 'cheap trick' is to temporarily provide the problematic certs under
> review to your *webmail* daemon and restart it.
>
> Browsers are very quick to throw a flag, point out the vagaries, present
> all the info in an easy to read manner... THEN ALSO -- allow a manual
> over-ride so you can check and see if the NEXT phase is working as
> planned... tail -f on the inside log as well to get an opnio from Exim.
>
> Not as realistic as, say swaks, or ssl/ssh built-in debug tools - but far
> easier than deciphering the millimeter-at-a-time *output* of '-vvv'
> and the like...
>
> YMMV
>
> Bill
> 韓家標
>
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
