| 88 | | Given all this, you can see that this is quite hard to document. I'm actually rather surprised that this API was chosen by OpenVPN, rather than doing something that produces an exact match on DN, requires that the cert be in the validity period, requires that the cert has reasonable attributes (e.g. meets the 'purpose' test for webserver (client) validation, etc) There are other APIs documented for the certificate store, but they do require more work. |
| | 88 | Given all this, you can see that this is quite hard to document. I'm actually rather surprised that this API was chosen by OpenVPN, rather than doing something that produces an exact match on DN, requires that the cert be in the validity period, requires that the cert has reasonable attributes (e.g. meets the 'purpose' test for webserver (client) validation, etc) There are other APIs documented for the certificate store, but they do require more work. Also, OpenVPN really should only tell the search to only consider certificates from the "acceptable CA" list published by the server - which, since OpenVPN doesn't have a separate list, is the '''--ca''' / '''--capath''' list. (For the preferred server behavior, see Apache HTTPD's '''SSLCADNRequestFile''' and '''SSLCADNRequestPath''' directives at http://httpd.apache.org/docs/current/mod/mod_ssl.html#SSLCADNRequestFile. Analogously, OpenVPN should have '''--Acceptable-ca''' and '''--Acceptable-capath''' options for the server.) |
