So the error is the "double hop." I don't think you can use the impersonate for remote connections to the server that is housing the linked server. Best to give it a local user on the second server.
It is definitely easier to use a sql login for the linked server. However, it's not terribly difficult to troubleshoot windows authentication/delegation/kerberos issues.
The link posted by SQLKnowItAll hits the high points, but misses some stumbling blocks.
Connect as myDomain\Usr to SqlServer1.myDomain.local (running as myDomain\SqlSrv1Svc) then access a linked server using windows authentication to SqlServer2.myDomain.local (running as myDomain\SqlSrv2Svc).
1. Verify that you can authenticate to SqlServer1 using Kerberos instead of NTLM.
SELECT auth_scheme FROM sys.dm_exec_connections
WHERE session_id = @@spid
If it's showing NTLM, then check the following: http://msdn.microsoft.com/en-us/library/ms191153.aspx
Also, this seems to be a good reference as well: http://technet.microsoft.com/library/ee191523.aspx
One additional gotcha is that you have to use DNS "A" records, not CNAMEs for the Servers. (Kerberos doesn't work with CNAMEs)
2. Verify that you can authenticate directly to SqlServer2 using Kerberos instead of NTLM.
3. Verify that myDomain\SqlSrv1Svc is trusted for delegation to MSSQLSvc:SqlServer2.myDomain.local
Piece of Cake!