<div dir="ltr">I made some progress debugging this. For a start, I changed the DN of my client's self-signed cert to be based on timestamp (this is generated every 30seconds when IPsec is down).<br><div><br></div><div>With this change, I now do NOT see "signature validation failed" error. However, now I see "no matching peer config found" on the server.</div><div><br></div><div>Here is what is happening:</div><div>Client:</div><div>1) Boots up</div><div>2) Generates cert with DN=timestamp1</div><div>3) IPsec up; all good</div><div>4) Server brought down; IPsec goes down</div><div>5) Client retries every 30 seconds; each retry involves "ipsec stop", "generate new private key, self signed cert with DN=different timestamp", "ipsec start"</div><div>....</div><div>6) Server comes up; generates its own private key and self-signed cert.</div><div>7) strongswan receives end-entity cert from client with <i>DN=ts1</i> (??)</div><div><br></div><div>I see client strongswan logs report "sending end entity cert with DN=ts1" even after IPsec has been stopped and restarted a number of times and the cert with DN=ts1 is no longer on the filesystem! </div><div><br></div><div>Server strongswan logs report "no matching peer config found" which might be expected given the cert they are looking for is DN=tsn (n > 1 depending on when server came up).</div><div><br></div><div>Thanks.</div><div>Piyush</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 10:40 AM, Piyush Agarwal <span dir="ltr"><<a href="mailto:agarwalpiyush@gmail.com" target="_blank">agarwalpiyush@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>I am running into a strange issue and would appreciate any help in debugging what could be going wrong.</div><div><br></div><div>I am using self-signed certs for both my client and server. Client sends its cert to server (via out of band channel) and vice-versa so that verification can be done. </div><div><br></div><div>I am using the same subject DN for both my client and server (again, as bad as this is, this works for our setup).</div><div><br></div><div>All is good and IPsec comes up. Now I am simulating failure scenario where the server dies and restarts after say 40 seconds and expect IPsec to come up again because client is programmed to retry every 30 seconds. [BTW, the client here is detecting the server is down by checking output of setkey -D to see if mature bi-directional IPsec SAs are present or not]</div><div><br></div><div>Client logic on detecting IPsec down for 30 seconds (Start state is IPsec transport tunnel established):</div><div>==============================<wbr>==========</div><div>1) Call ipsec stop</div><div>2) Receive out of band event that server is up, connect to server</div><div>3) Regenerate private key and store in ipsec.d/private/</div><div>4) Regenerate self-signed cert and store in ipsec.d/certs/client.cert</div><div>3) Get server's self-signed cert and store in local ipsec.d/certs/server.cert. Send client's self-signed cert to server</div><div>4) ipsec start to bring tunnel up</div><div><br></div><div>Server events (Start state is IPsec transport tunnel established):</div><div>===========</div><div>1) Server is shut down resulting in ipsec daemon stopping</div><div>2) After 40 seconds, server restarts</div><div>3) Generate private key and store in ipsec.d/private/</div><div>4) Generate self-signed cert and store in ipsec.d/certs/server.cert</div><div>5) Receives out of band event that client is trying to register<br clear="all"><div>6) Send own cert to client and store client's cert in ipsec.d/certs/client.cert</div><div>7) ipsec start to bring tunnel up</div><div>7.1) Each subsequent client re-attempt (30 seconds), will lead to "ipsec reload" and not "ipsec stop/start" cycle on server end.</div><div><br></div><div>At this point the server logs complain the following:</div><div><div><b>07[CFG] selected peer config 'x.x.x.x'</b></div><div><b>07[CFG]   using trusted certificate "ABCDEFGH"</b></div><div><b>07[IKE] signature validation failed, looking for another key</b></div></div><div><br></div><div>Appreciate any guidance. </div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_534034763135788369gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">Piyush Agarwal</span><br></div><div><span style="color:rgb(17,17,17)"><font face="arial, helvetica, sans-serif" size="2">Life can only be understood backwards; but it must be lived forwards.</font></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">Piyush Agarwal</span><br></div><div><span style="color:rgb(17,17,17)"><font face="arial, helvetica, sans-serif" size="2">Life can only be understood backwards; but it must be lived forwards.</font></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>