[strongSwan] signature validation failed error

[Piyush Agarwal]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170515/31266e76/attachment-0001.html>