On 10-Apr-14 05:57, openvpn-users-requ...@lists.sourceforge.net wrote:
It's one of the world's most confusing messages, and should be a textbook example of why it's important to write documentation from the point of view of the user, not the programmer.Hi Erich, >>> >>Still... the error message is bogus. >>>glad to hear that this has been resolved. I agree that the error message >is bogus, but this is what you get back from OpenSSL - and it's quite >hard to tell whether this is due to a missing CA cert, an untrusted CA >cert or whether it is simply a self-signed certificate.Which by itself is not an error and it should only be thrown if the self signed certificate is_present_ at all.I guess it could>be added as an extended check but it's not something you'd want to do >for every client connecting to a server.Why should you? The client reports it. At that moment it gets the certificate, either its own or the one from the server, it does not really matter. It then somehow tries to verify the validity and fails, because it has no information about issuer (because it is missing). At that very moment only it needs to be decided what the real cause of the error is. Having read a number of threads on this bogus error leads me to the conclusion, that the 'self signed' error just means 'cannot verify validity' and I am pretty sure this can be decoded somehow. Do you have insight where in the code this error is thrown? Thanks Erich
What it means is that in tracing the certificate chain, a self-signed certificate was encountered that is NOT in your trusted CA list and/or is not marked as a CA.
To further confuse matters, certificates that are marked TRUSTED (openssl x509 -settrust) aren't accepted by most servers. This is DIFFERENT from 'trusted' in the sense of of 'trusted ca authority'. The former is an attribute stored in the certificate; the latter is the the certificate's presence in (for openssl) the cafile or capath list of trusted authorities.
The error comes from deep in OpenSSL; the problem is not unique to OpenVPN - happens with web (and e-mail) servers all the time. Endless person-hours have been spent figuring this out - over and over again.
You can raise the issue with the openssl folks - it isn't an OpenVPN issue, nor is OpenVPN the place to solve it. I'm not optimistic that openssl can/will do much about it.
To reproduce this (and get slightly better diagnostics - for a human), use the openssl verify command on the certificate. And/or openssl s_client to connect to a server that uses it. (s_client doesn't work with OpenVPN, but does if the same certificate is installed in a web/mail server.) With this, you can trace the verification process and see at which certificate it stops. You can also (with -showcerts) get the intermediate certificates and decode them.
Despite the universally bad error messages- and the recent bug - OpenSSL has made a great contribution to making crypto accessible, and the Internet more secure. So I cut them some slack.
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
