Indeed, that is the interesting question. This has to do with how the client certificate is signed by the client, which in TLS1.2 is negotiated between the client and server - and depends on the available/selected ciphers."why is it breaking for you in particular, while it works for other Linux users just fine" (half of my testbed is Linux...)
As I wrote here: http://sourceforge.net/p/openvpn/mailman/message/32265218/, I believe I know where this is coming from, just not why. I'd like to set a breakpoint in the client and forward/back track to find out. George: One way to do that would be what I suggested here: http://sourceforge.net/p/openvpn/mailman/message/32264919/ Is this feasible? At this point, I think it would be the most efficient way to proceed. I could give you instructions for creating a process dump - but a dump file would have more secrets in it than what I suggested. The two referenced mail messages are as far as I got by inspection. On 28-Apr-14 11:22, Gert Doering wrote:
Hi, On Mon, Apr 28, 2014 at 04:04:10PM +0100, George Ross wrote:OK, with the attached patch it does appear to work for me. I'll give it some more exercise tomorrow morning, but in a quick test the tunnel does now appear to come up properly.Thanks. That confirms the theory "it's the TLS negotiation patch", and in particular "TLS 1.1 works, TLS 1.2 breaks". Now the even more interesting question is "why is it breaking for you in particular, while it works for other Linux users just fine" (half of my testbed is Linux...) gert
smime.p7s
Description: S/MIME Cryptographic Signature
