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 <[email protected]> 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/ > -- ## 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/
