[strongSwan] signature validation failed error

[Piyush Agarwal]

Apologies. Turns out the issue was a messy filesystem due to using
overlayfs() and yet modifying the underlying filesystem directly.
Please ignore this thread.

On Mon, May 15, 2017 at 4:25 PM, Piyush Agarwal <agarwalpiyush at gmail.com>
wrote:

> 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).
>
> With this change, I now do NOT see "signature validation failed" error.
> However, now I see "no matching peer config found" on the server.
>
> Here is what is happening:
> Client:
> 1) Boots up
> 2) Generates cert with DN=timestamp1
> 3) IPsec up; all good
> 4) Server brought down; IPsec goes down
> 5) Client retries every 30 seconds; each retry involves "ipsec stop",
> "generate new private key, self signed cert with DN=different timestamp",
> "ipsec start"
> ....
> 6) Server comes up; generates its own private key and self-signed cert.
> 7) strongswan receives end-entity cert from client with *DN=ts1* (??)
>
> 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!
>
> 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).
>
> Thanks.
> Piyush
>
> On Mon, May 15, 2017 at 10:40 AM, Piyush Agarwal <agarwalpiyush at gmail.com>
> wrote:
>
>> Hi,
>> I am running into a strange issue and would appreciate any help in
>> debugging what could be going wrong.
>>
>> 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.
>>
>> I am using the same subject DN for both my client and server (again, as
>> bad as this is, this works for our setup).
>>
>> 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]
>>
>> Client logic on detecting IPsec down for 30 seconds (Start state is IPsec
>> transport tunnel established):
>> ========================================
>> 1) Call ipsec stop
>> 2) Receive out of band event that server is up, connect to server
>> 3) Regenerate private key and store in ipsec.d/private/
>> 4) Regenerate self-signed cert and store in ipsec.d/certs/client.cert
>> 3) Get server's self-signed cert and store in local
>> ipsec.d/certs/server.cert. Send client's self-signed cert to server
>> 4) ipsec start to bring tunnel up
>>
>> Server events (Start state is IPsec transport tunnel established):
>> ===========
>> 1) Server is shut down resulting in ipsec daemon stopping
>> 2) After 40 seconds, server restarts
>> 3) Generate private key and store in ipsec.d/private/
>> 4) Generate self-signed cert and store in ipsec.d/certs/server.cert
>> 5) Receives out of band event that client is trying to register
>> 6) Send own cert to client and store client's cert in
>> ipsec.d/certs/client.cert
>> 7) ipsec start to bring tunnel up
>> 7.1) Each subsequent client re-attempt (30 seconds), will lead to "ipsec
>> reload" and not "ipsec stop/start" cycle on server end.
>>
>> At this point the server logs complain the following:
>> *07[CFG] selected peer config 'x.x.x.x'*
>> *07[CFG]   using trusted certificate "ABCDEFGH"*
>> *07[IKE] signature validation failed, looking for another key*
>>
>> Appreciate any guidance.
>> --
>> Piyush Agarwal
>> Life can only be understood backwards; but it must be lived forwards.
>>
>
>
>
> --
> Piyush Agarwal
> Life can only be understood backwards; but it must be lived forwards.
>



-- 
Piyush Agarwal
Life can only be understood backwards; but it must be lived forwards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170516/c8ad9bf9/attachment-0001.html>