-
Notifications
You must be signed in to change notification settings - Fork 746
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve debug logging around certificate validation #1712
Comments
That was me and the issue is quite common (i.e. easily identifiable). Actually, it even has its own FAQ entry with a kind of checklist. However, in your case it has nothing to do with the actual certificate validation. It happens before that because there is no public key available (which could be contained in a certificate, but does not have to be) that matches the peer's identity, which is exactly what the log message states. |
I appreciate you linking the FAQ - I wasn't able to find this at the time, even after searching for the relevant string & strongswan together on Google. That being said, even with the FAQ, it may be obvious to someone who is very familiar with IPsec / strongSwan, but I would have found it very hard to draw that conclusion from what is actually being logged - I agree, now you've pointed it out, I can see where you are saying it did log that, but to the uninitiated, it isn't very clearly explained by those log lines in an easily understandable way. I initially started debugging this on Chrome OS, and without wiping your entire machine & putting it into developer mode (which I ended up doing in the end), you can't actually check what certificates & trusted CAs are being passed into the daemon, and the log to me read as if the CA certificate wasn't being placed in the trust store. If you don't want to change it, that's fine, but as feedback, it would be helpful if it points it out specifically a little more. |
Yeah, kinda weird. In a Google search for To be fair, we always ask people to check the FAQ as a first step (e.g. here, which is linked on the support page, or in #196).
Changing that log message is tricky, as where it's logged we only know what it already states, i.e. that no trusted key was found for that identity. We don't know if there actually was a matching key/certificate but it couldn't be validated, or if that couldn't even be attempted because no matching certificate was found. However, as a user you can differentiate these cases due to the absence of other log message. Because if a matching certificate was found, you'd see |
Is your feature request related to a problem? Please describe.
When using IKEv2 certificate based authentication, if validation fails for the server certificate, the logging is very poor around the reason & it's very difficult to debug - even on the highest debug level, you get a binary dump of the packets, but no explanation of the logic being used for the validation, or a reason it was rejected.
I had a problem where the remote endpoint (also actually running strongSwan on pfSense, and being used for Windows 10/11 AlwaysOn Device Tunnel) was being rejected on Linux clients, even thought it works perfectly on Windows clients, and it was very hard to figure out why.
Eventually, I posted the logs on IRC and user
ecsda
replied very quickly to say it was the remote server presenting an IP as it's identity rather than the FQDN we were connecting to (and what was listed on the SAN in the certificate).This validation logic wasn't obvious at all from the logs and even reading the source code: I'm fairly competent reading code, but with limited understanding of the code base & not a lot of time, I couldn't figure it out - it also doesn't seem to be documented anywhere.
Describe the solution you'd like
Better logging, especially at level 1.
Include a simple explanation of what is being validated and if rejected, what caused the rejection.
Describe alternatives you've considered
Hours & hours of debugging that could otherwise be avoided....? :).
Additional context
Relevant snippet of the logs where it fails:
The text was updated successfully, but these errors were encountered: