openvpn-devel Mailing List for OpenVPN

That's what I did and it worked great ! Thanks a lot !! :) Sagi On 27 בפבר 2013, at 20:43, Samuli Seppänen <sa...@op...> wrote: > Hi, > > You can use openvpn-build to build openvpn and it's dependencies, including the OpenVPN-GUI - that should just work. Once the build is finished, you can probably hack the openvpn-build scripts to only build the GUI. > > Best regards, > -- > Samuli Seppänen > Community Manager > OpenVPN Technologies, Inc > > irc freenode net: mattock > > [1] > openvpn-build/generic/build > openvpn-build/windows-nsis/build-complete > > >> Hi All, >> >> I've installed all required programs as written in 1. >> >> apt-get install git-core mingw-w64 gcc-4.6-arm-linux-gnueabi man2html dos2unix nsis unzip >> >> Then, I've executed the command ./configure --prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc inside OpenVPN-Gui source folder. >> >> It completed successfully, then when I execute the command make i get the following error: >> >> main.c:26:21: fatal error: windows.h: No such file or directory >> compilation terminated. >> make[1]: *** [main.o] Error 1 >> >> What I'm doing wrong? >> >> Thanks, >> Sagi >> >> [1] https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem > > 

Hi, You can use openvpn-build to build openvpn and it's dependencies, including the OpenVPN-GUI - that should just work. Once the build is finished, you can probably hack the openvpn-build scripts to only build the GUI. Best regards, -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] openvpn-build/generic/build openvpn-build/windows-nsis/build-complete > Hi All, > > I've installed all required programs as written in 1. > > apt-get install git-core mingw-w64 gcc-4.6-arm-linux-gnueabi man2html > dos2unix nsis unzip > > Then, I've executed the command ./configure > --prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc inside > OpenVPN-Gui source folder. > > It completed successfully, then when I execute the command make i get > the following error: > > main.c:26:21: fatal error: windows.h: No such file or directory > compilation terminated. > make[1]: *** [main.o] Error 1 > > What I'm doing wrong? > > Thanks, > Sagi > > [1] https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 

Hi All, I've installed all required programs as written in 1. apt-get install git-core mingw-w64 gcc-4.6-arm-linux-gnueabi man2html dos2unix nsis unzip Then, I've executed the command ./configure --prefix=/usr/local/i586-mingw32 --host=i586-mingw32msvc inside OpenVPN-Gui source folder. It completed successfully, then when I execute the command make i get the following error: main.c:26:21: fatal error: windows.h: No such file or directory compilation terminated. make[1]: *** [main.o] Error 1 What I'm doing wrong? Thanks, Sagi [1] https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 

Add the option --verify-x509-name to provide the functionality of the now deprecated --tls-remote. The new option accepts RFC 2253 subject DNs only and compares RDN or RDN prefix only if configured explicitly. Signed-off-by: Heiko Hund <hei...@so...> --- doc/openvpn.8 | 78 +++++++++++++++++++++++++++++++------- src/openvpn/init.c | 7 ++-- src/openvpn/options.c | 94 ++++++++++++++++++++++++++++++++++++++++------ src/openvpn/options.h | 3 +- src/openvpn/ssl_common.h | 3 +- src/openvpn/ssl_verify.c | 15 +++++--- src/openvpn/ssl_verify.h | 6 +++ 7 files changed, 170 insertions(+), 36 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 998f7ab..637fbb4 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -3431,7 +3431,7 @@ the authenticated username as the common name, rather than the common name from the client cert. .\"********************************************************* .TP -.B \-\-compat\-names [no\-remapping] +.B \-\-compat\-names [no\-remapping] (DEPRECATED) Until OpenVPN v2.3 the format of the X.509 Subject fields was formatted like this: .IP @@ -3467,17 +3467,20 @@ The mode flag can be used with the .B \-\-compat\-names -option to be compatible with the now deprecated \-\-no\-name\-remapping feature -present in older OpenVPN versions. When this mode flag is used, the Common Name, +option to be compatible with the now deprecated \-\-no\-name\-remapping option. +It is only available at the server. When this mode flag is used, the Common Name, Subject, and username strings are allowed to include any printable character including space, but excluding control characters such as tab, newline, and -carriage-return. +carriage-return. no-remapping is only available on the server side. .B Please note: -This option will not be around for a long time. It is only implemented +This option is immediately deprecated. It is only implemented to make the transition to the new formatting less intrusive. It will be -removed either in OpenVPN v2.4 or v2.5. So please make sure you start -the process to support the new formatting as soon as possible. +removed either in OpenVPN v2.4 or v2.5. So please make sure you use the +.B \-\-verify-x509-name +option instead of +.B \-\-tls-remote +as soon as possible and update your scripts where necessary. .\"********************************************************* .TP .B \-\-no\-name\-remapping (DEPRECATED) @@ -3485,7 +3488,7 @@ The .B \-\-no\-name\-remapping option is an alias for .B \-\-compat\-names\ no\-remapping. -It ensures compatibility with configurations using the +It ensures compatibility with server configurations using the .B \-\-no\-name\-remapping option. @@ -4671,11 +4674,11 @@ is available via the peer_cert environment variable. Field in x509 certificate subject to be used as username (default=CN). .B Fieldname will be uppercased before matching. When this option is used, the ---tls-remote option will match against the chosen fieldname instead -of the CN. +.B \-\-verify-x509-username +option will match against the chosen fieldname instead of the CN. .\"********************************************************* .TP -.B \-\-tls-remote name +.B \-\-tls-remote name (DEPRECATED) Accept connections only from a host with X509 name or common name equal to .B name. @@ -4707,6 +4710,55 @@ option to verify the remote host, because works in a .B \-\-chroot environment too. + +.B Please also note: +This option is now deprecated. It will be removed either in OpenVPN v2.4 +or v2.5. So please make sure you support the new X.509 name formatting +described with the +.B \-\-compat-names +option as soon as possible by updating your configurations to use +.B \-\-verify-x509-name +instead. +.\"********************************************************* +.TP +.B \-\-verify-x509-name name type +Accept connections only if a host's X.509 name is equal to +.B name. +The remote host must also pass all other tests of verification. + +Which X.509 name is compared to +.B name +depends on the setting of type. +.B type +can be "subject" to match the complete subject DN (default), +"name" to match a subject RDN or "name-prefix" to match a subject RDN prefix. +Which RDN is verified as name depends on the +.B \-\-x509-username-field +option. But it defaults to the common name (CN). + +.B \-\-verify-x509-name +is a useful replacement for the +.B \-\-tls-verify +option to verify the remote host, because +.B \-\-verify-x509-name +works in a +.B \-\-chroot +environment too. + +If you want a client to only accept connections +to "Server-1", "Server-2", etc., you can simply use +.B \-\-verify-x509-name Server- name-prefix + +Using a name prefix is a useful alternative to managing +a CRL (Certificate Revocation List) on the client, since it allows the client +to refuse all certificates except for those associated +with designated servers. + +.B NOTE: +Test against a name prefix only when you are using OpenVPN with +a custom CA certificate that is under your control. +Never use this option with type "name-prefix" when your client certificates +are signed by a third party, such as a commercial web CA. .\"********************************************************* .TP .B \-\-x509-track attribute @@ -4744,7 +4796,7 @@ a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of -.B \-\-ns-cert-type, \-\-tls-remote, +.B \-\-ns-cert-type, \-\-verify-x509-name, or .B \-\-tls-verify. .\"********************************************************* @@ -4802,7 +4854,7 @@ a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of -.B \-\-remote-cert-tls, \-\-tls-remote, +.B \-\-remote-cert-tls, \-\-verify-x509-name, or .B \-\-tls-verify. .\"********************************************************* diff --git a/src/openvpn/init.c b/src/openvpn/init.c index 25d8225..979ba23 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -2205,7 +2205,8 @@ do_init_crypto_tls (struct context *c, const unsigned int flags) to.verify_command = options->tls_verify; to.verify_export_cert = options->tls_export_cert; - to.verify_x509name = options->tls_remote; + to.verify_x509_type = (options->verify_x509_type & 0xff); + to.verify_x509_name = options->verify_x509_name; to.crl_file = options->crl_file; to.ssl_flags = options->ssl_flags; to.ns_cert_type = options->ns_cert_type; @@ -2467,12 +2468,10 @@ do_option_warnings (struct context *c) warn_on_use_of_common_subnets (); if (o->tls_client && !o->tls_verify - && !o->tls_remote + && o->verify_x509_type == VERIFY_X509_NONE && !(o->ns_cert_type & NS_CERT_CHECK_SERVER) && !o->remote_cert_eku) msg (M_WARN, "WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info."); - if (o->tls_remote) - msg (M_WARN, "WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page)."); #endif #endif diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 7fda76f..8592955 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -614,8 +614,8 @@ static const char usage_message[] = "--tls-export-cert [directory] : Get peer cert in PEM format and store it \n" " in an openvpn temporary file in [directory]. Peer cert is \n" " stored before tls-verify script execution and deleted after.\n" - "--tls-remote x509name: Accept connections only from a host with X509 name\n" - " x509name. The remote host must also pass all other tests\n" + "--verify-x509-name name: Accept connections only from a host with X509 subject\n" + " DN name. The remote host must also pass all other tests\n" " of verification.\n" "--ns-cert-type t: Require that peer certificate was signed with an explicit\n" " nsCertType designation t = 'client' | 'server'.\n" @@ -1596,7 +1596,8 @@ show_settings (const struct options *o) SHOW_STR (cipher_list); SHOW_STR (tls_verify); SHOW_STR (tls_export_cert); - SHOW_STR (tls_remote); + SHOW_INT (verify_x509_type); + SHOW_STR (verify_x509_name); SHOW_STR (crl_file); SHOW_INT (ns_cert_type); { @@ -2130,7 +2131,6 @@ options_postprocess_verify_ce (const struct options *options, const struct conne if (options->stale_routes_check_interval) msg (M_USAGE, "--stale-routes-check requires --mode server"); - if (compat_flag (COMPAT_FLAG_QUERY | COMPAT_NO_NAME_REMAPPING)) msg (M_USAGE, "--compat-x509-names no-remapping requires --mode server"); } @@ -2302,7 +2302,7 @@ options_postprocess_verify_ce (const struct options *options, const struct conne MUST_BE_UNDEF (cipher_list); MUST_BE_UNDEF (tls_verify); MUST_BE_UNDEF (tls_export_cert); - MUST_BE_UNDEF (tls_remote); + MUST_BE_UNDEF (verify_x509_name); MUST_BE_UNDEF (tls_timeout); MUST_BE_UNDEF (renegotiate_bytes); MUST_BE_UNDEF (renegotiate_packets); @@ -6514,27 +6514,97 @@ add_option (struct options *options, else if (streq (p[0], "compat-names")) { VERIFY_PERMISSION (OPT_P_GENERAL); + if (options->verify_x509_type != VERIFY_X509_NONE && + options->verify_x509_type != TLS_REMOTE_SUBJECT_DN && + options->verify_x509_type != TLS_REMOTE_SUBJECT_RDN_PREFIX) + { + msg (msglevel, "you cannot use --compat-names with --verify-x509-name"); + goto err; + } + msg (M_WARN, "DEPRECATED OPTION: --compat-names, please update your configuration"); compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); +#if P2MP_SERVER if (p[1] && streq (p[1], "no-remapping")) compat_flag (COMPAT_FLAG_SET | COMPAT_NO_NAME_REMAPPING); } else if (streq (p[0], "no-name-remapping")) { VERIFY_PERMISSION (OPT_P_GENERAL); + if (options->verify_x509_type != VERIFY_X509_NONE && + options->verify_x509_type != TLS_REMOTE_SUBJECT_DN && + options->verify_x509_type != TLS_REMOTE_SUBJECT_RDN_PREFIX) + { + msg (msglevel, "you cannot use --no-name-remapping with --verify-x509-name"); + goto err; + } msg (M_WARN, "DEPRECATED OPTION: --no-name-remapping, please update your configuration"); compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); compat_flag (COMPAT_FLAG_SET | COMPAT_NO_NAME_REMAPPING); +#endif } else if (streq (p[0], "tls-remote") && p[1]) { VERIFY_PERMISSION (OPT_P_GENERAL); - /* - * Enable legacy openvpn format for DNs that have not been converted - * yet and X.509 common names (not containing an '=' or ', ') - */ - if (p[1][0] == '/' || !strchr (p[1], '=') || !strstr (p[1], ", ")) - compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); - options->tls_remote = p[1]; + + if (options->verify_x509_type != VERIFY_X509_NONE && + options->verify_x509_type != TLS_REMOTE_SUBJECT_DN && + options->verify_x509_type != TLS_REMOTE_SUBJECT_RDN_PREFIX) + { + msg (msglevel, "you cannot use --tls-remote with --verify-x509-name"); + goto err; + } + msg (M_WARN, "DEPRECATED OPTION: --tls-remote, please update your configuration"); + + if (strlen (p[1])) + { + int is_username = (!strchr (p[1], '=') || !strstr (p[1], ", ")); + int type = TLS_REMOTE_SUBJECT_DN; + if (p[1][0] != '/' && is_username) + type = TLS_REMOTE_SUBJECT_RDN_PREFIX; + + /* + * Enable legacy openvpn format for DNs that have not been converted + * yet and --x509-username-field (not containing an '=' or ', ') + */ + if (p[1][0] == '/' || is_username) + compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); + + options->verify_x509_type = type; + options->verify_x509_name = p[1]; + } + } + else if (streq (p[0], "verify-x509-name") && p[1] && strlen (p[1])) + { + int type = VERIFY_X509_SUBJECT_DN; + VERIFY_PERMISSION (OPT_P_GENERAL); + if (options->verify_x509_type == TLS_REMOTE_SUBJECT_DN || + options->verify_x509_type == TLS_REMOTE_SUBJECT_RDN_PREFIX) + { + msg (msglevel, "you cannot use --verify-x509-name with --tls-remote"); + goto err; + } + if (compat_flag (COMPAT_FLAG_QUERY | COMPAT_NAMES)) + { + msg (msglevel, "you cannot use --verify-x509-name with " + "--compat-names or --no-name-remapping"); + goto err; + } + if (p[2]) + { + if (streq (p[2], "subject")) + type = VERIFY_X509_SUBJECT_DN; + else if (streq (p[2], "name")) + type = VERIFY_X509_SUBJECT_RDN; + else if (streq (p[2], "name-prefix")) + type = VERIFY_X509_SUBJECT_RDN_PREFIX; + else + { + msg (msglevel, "unknown X.509 name type: %s", p[2]); + goto err; + } + } + options->verify_x509_type = type; + options->verify_x509_name = p[1]; } else if (streq (p[0], "ns-cert-type") && p[1]) { diff --git a/src/openvpn/options.h b/src/openvpn/options.h index 306520b..d2ad94c 100644 --- a/src/openvpn/options.h +++ b/src/openvpn/options.h @@ -506,8 +506,9 @@ struct options const char *pkcs12_file; const char *cipher_list; const char *tls_verify; + int verify_x509_type; + const char *verify_x509_name; const char *tls_export_cert; - const char *tls_remote; const char *crl_file; const char *ca_file_inline; diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h index cb259a9..c62294f 100644 --- a/src/openvpn/ssl_common.h +++ b/src/openvpn/ssl_common.h @@ -245,7 +245,8 @@ struct tls_options /* cert verification parms */ const char *verify_command; const char *verify_export_cert; - const char *verify_x509name; + int verify_x509_type; + const char *verify_x509_name; const char *crl_file; int ns_cert_type; unsigned remote_cert_ku[MAX_PARMS]; diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c index cac46e9..e651a8e 100644 --- a/src/openvpn/ssl_verify.c +++ b/src/openvpn/ssl_verify.c @@ -369,16 +369,21 @@ verify_peer_cert(const struct tls_options *opt, openvpn_x509_cert_t *peer_cert, #endif /* OPENSSL_VERSION_NUMBER */ - /* verify X509 name or common name against --tls-remote */ - if (opt->verify_x509name && strlen (opt->verify_x509name) > 0) + /* verify X509 name or username against --verify-x509-[user]name */ + if (opt->verify_x509_type != VERIFY_X509_NONE) { - if (strcmp (opt->verify_x509name, subject) == 0 - || strncmp (opt->verify_x509name, common_name, strlen (opt->verify_x509name)) == 0) + if ( (opt->verify_x509_type == VERIFY_X509_SUBJECT_DN + && strcmp (opt->verify_x509_name, subject) == 0) + || (opt->verify_x509_type == VERIFY_X509_SUBJECT_RDN + && strcmp (opt->verify_x509_name, common_name) == 0) + || (opt->verify_x509_type == VERIFY_X509_SUBJECT_RDN_PREFIX + && strncmp (opt->verify_x509_name, common_name, + strlen (opt->verify_x509_name)) == 0) )	msg (D_HANDSHAKE, "VERIFY X509NAME OK: %s", subject); else	{ msg (D_HANDSHAKE, "VERIFY X509NAME ERROR: %s, must be %s", - subject, opt->verify_x509name); + subject, opt->verify_x509_name); return FAILURE;	/* Reject connection */	} } diff --git a/src/openvpn/ssl_verify.h b/src/openvpn/ssl_verify.h index 1d20152..e0bcba4 100644 --- a/src/openvpn/ssl_verify.h +++ b/src/openvpn/ssl_verify.h @@ -62,6 +62,12 @@ struct cert_hash_set { struct cert_hash *ch[MAX_CERT_DEPTH]; /**< Array of certificate hashes */ }; +#define VERIFY_X509_NONE 0 +#define VERIFY_X509_SUBJECT_DN 1 +#define VERIFY_X509_SUBJECT_RDN 2 +#define VERIFY_X509_SUBJECT_RDN_PREFIX 3 +#define TLS_REMOTE_SUBJECT_DN 1 + 0x100 +#define TLS_REMOTE_SUBJECT_RDN_PREFIX 3 + 0x100 #define TLS_AUTHENTICATION_SUCCEEDED 0 #define TLS_AUTHENTICATION_FAILED 1 -- 1.7.9.5 

In openvpn 2.3.0 the semantics of the --tls-remote option changed. That broke more configurations than anticipated. To not break configurations that use --tls-remote with a legacy OpenSSL style DN anymore, it is now detected when such a DN is configured. When necessary the --compat-names option is then automatically enabled. Signed-off-by: Heiko Hund <hei...@so...> --- src/openvpn/options.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index dd38bc9..7fda76f 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -6528,6 +6528,12 @@ add_option (struct options *options, else if (streq (p[0], "tls-remote") && p[1]) { VERIFY_PERMISSION (OPT_P_GENERAL); + /* + * Enable legacy openvpn format for DNs that have not been converted + * yet and X.509 common names (not containing an '=' or ', ') + */ + if (p[1][0] == '/' || !strchr (p[1], '=') || !strstr (p[1], ", ")) + compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); options->tls_remote = p[1]; } else if (streq (p[0], "ns-cert-type") && p[1]) -- 1.7.9.5 

The option is just an alias for --compat-names no-remapping and is introduced so pre-2.3 server configurations don't break. Signed-off-by: Heiko Hund <hei...@so...> --- doc/openvpn.8 | 32 +++++++++++++++++++++++--------- src/openvpn/options.c | 21 ++++++++++++++------- 2 files changed, 37 insertions(+), 16 deletions(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 829bbd2..998f7ab 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -3462,19 +3462,16 @@ characters in the usernames, X.509 Subject fields and Common Name variables and it complies to the RFC 2253, UTF\-8 String Representation of Distinguished Names. -As a backwards compatibility for the removed \-\-no\-name\-remapping feature in -older OpenVPN versions, the +The .B no\-remapping mode flag can be used with the .B \-\-compat\-names -option. -When this mode flag is used, the Common Name, Subject, and username strings are -allowed to include any printable character including space, but excluding -control characters such as tab, newline, and carriage-return. It ensures -compatibility with the -.B \-\-no\-name\-remapping -option of OpenVPN versions before v2.3. +option to be compatible with the now deprecated \-\-no\-name\-remapping feature +present in older OpenVPN versions. When this mode flag is used, the Common Name, +Subject, and username strings are allowed to include any printable character +including space, but excluding control characters such as tab, newline, and +carriage-return. .B Please note: This option will not be around for a long time. It is only implemented @@ -3483,6 +3480,23 @@ removed either in OpenVPN v2.4 or v2.5. So please make sure you start the process to support the new formatting as soon as possible. .\"********************************************************* .TP +.B \-\-no\-name\-remapping (DEPRECATED) +The +.B \-\-no\-name\-remapping +option is an alias for +.B \-\-compat\-names\ no\-remapping. +It ensures compatibility with configurations using the +.B \-\-no\-name\-remapping +option. + +.B Please note: +This option is now deprecated. It will be removed either in OpenVPN v2.4 +or v2.5. So please make sure you support the new X.509 name formatting +described with the +.B \-\-compat\-names +option as soon as possible. +.\"********************************************************* +.TP .B \-\-port-share host port [dir] When run in TCP server mode, share the OpenVPN port with another application, such as an HTTPS server. If OpenVPN diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 3b5f1e7..dd38bc9 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -5561,13 +5561,6 @@ add_option (struct options *options, VERIFY_PERMISSION (OPT_P_GENERAL); options->ssl_flags |= SSLF_AUTH_USER_PASS_OPTIONAL; } - else if (streq (p[0], "compat-names")) - { - VERIFY_PERMISSION (OPT_P_GENERAL); - compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); - if (p[1] && streq (p[1], "no-remapping")) - compat_flag (COMPAT_FLAG_SET | COMPAT_NO_NAME_REMAPPING); - } else if (streq (p[0], "opt-verify")) { VERIFY_PERMISSION (OPT_P_GENERAL); @@ -6518,6 +6511,20 @@ add_option (struct options *options, options->tls_export_cert = p[1]; } #endif + else if (streq (p[0], "compat-names")) + { + VERIFY_PERMISSION (OPT_P_GENERAL); + compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); + if (p[1] && streq (p[1], "no-remapping")) + compat_flag (COMPAT_FLAG_SET | COMPAT_NO_NAME_REMAPPING); + } + else if (streq (p[0], "no-name-remapping")) + { + VERIFY_PERMISSION (OPT_P_GENERAL); + msg (M_WARN, "DEPRECATED OPTION: --no-name-remapping, please update your configuration"); + compat_flag (COMPAT_FLAG_SET | COMPAT_NAMES); + compat_flag (COMPAT_FLAG_SET | COMPAT_NO_NAME_REMAPPING); + } else if (streq (p[0], "tls-remote") && p[1]) { VERIFY_PERMISSION (OPT_P_GENERAL); -- 1.7.9.5 

This patch set tries to do X.509 name verification right. As discussed during FOSDEM 2013, changing --tls-remote to support RFC 2253 style subject DNs only was too radical as it broke more configurations than expected. This makes --tls-remote work with old configurations again, but deprecates its use. As a replacement it introduces a new option for X.509 name verification that takes RFC 2253 subject DNs only. [PATCH 1/3] reintroduce --no-name-remapping option [PATCH 2/3] make --tls-remote compatible with pre 2.3 configs [PATCH 3/3] add new option for X.509 name verification 

Chris J Arges wrote: > This patch allows one to specify --pkcs11-id auto to automatically > select the first certificate on a pkcs11 device. This simplifies > scripts and usage in environments where clients may only use a single > certificate for connecting to a VPN. > Based on a patch by Oliver Dumschat-Hötte. > > some security-minded (paranoid?) folks will say that you should never automatically select a certificate/key pair (which is what a normal user would want, of course). This patch does seem like a useful addition, and it actually restores some functionality found in earlier versions of OpenVPN, IIRC. Perhaps more warnings should be added about this being a (minor) security risk. A man page snippet for this is missing from the patch, but that can be done if the patch is ACKed by others. I'm not authoratitive on ACKing patches, but as far as I am concerned: ACK JJK > Reported-by: Oliver Dumschat-Hötte <o.d...@tr...> > Signed-off-by: Chris J Arges <chr...@ca...> > --- > src/openvpn/pkcs11.c | 41 +++++++++++++++++++++++++++++++++-------- > 1 file changed, 33 insertions(+), 8 deletions(-) > > diff --git a/src/openvpn/pkcs11.c b/src/openvpn/pkcs11.c > index 3a15ef6..11d5e8f 100644 > --- a/src/openvpn/pkcs11.c > +++ b/src/openvpn/pkcs11.c > @@ -669,14 +669,39 @@ tls_ctx_use_pkcs11 ( >	} >	} >	else { > -	if ( > -	(rv = pkcs11h_certificate_deserializeCertificateId ( > -	&certificate_id, > -	pkcs11_id > -	)) != CKR_OK > -	) { > -	msg (M_WARN, "PKCS#11: Cannot deserialize id %ld-'%s'", rv, pkcs11h_getMessage (rv)); > -	goto cleanup; > +	if ( strcmp(pkcs11_id, "auto") == 0 ) { > +	char *pkcs11_id_read = NULL; > +	char *base64 = NULL; > +	if ( !pkcs11_management_id_get( > + 0, > + &pkcs11_id_read, > + &base64 > + ) > +	) { > +	msg (M_WARN, "PKCS#11: pkcs11_management_id_get 0 failed"); > +	goto cleanup; > +	} > +	if ( > +	(rv = pkcs11h_certificate_deserializeCertificateId ( > +	&certificate_id, > +	pkcs11_id_read > +	)) != CKR_OK > +	) { > +	msg (M_WARN, "PKCS#11: Cannot deserialize auto id %ld-'%s'", rv, > + pkcs11h_getMessage (rv)); > +	goto cleanup; > +	} > +	} else { > +	if ( > +	(rv = pkcs11h_certificate_deserializeCertificateId ( > +	&certificate_id, > +	pkcs11_id > +	)) != CKR_OK > +	) { > +	msg (M_WARN, "PKCS#11: Cannot deserialize id %ld-'%s'", rv, > + pkcs11h_getMessage (rv)); > +	goto cleanup; > +	} >	} >	} > > 

The patch is attached; a summary, and mitigating build suggestion follows: The current official Windows builds of 2.3.0 up to I004 are built enable_debug=no; I'm not sure about the repo builds since I build from source on my non-Windows systems, but the same issue is present when lacking debug support on Linux/Unix. This causes such builds to lack parameter printing at --verb 4 which conflicts with the help output and configure text for enable_small. This is a particular issue for binary installations (Windows, or binary *nix distros.) Until this change makes its way into the release repo branches, I'd suggest all official builds be built with enable_debug=yes. Without this build option, end-users will be unable to make use of increased verbosity/troubleshooting provided at verb 4. Commit/code reasoning for the patch: (also present in attached patch for convenience.) This patch applies to either the v2.3.0 tag, or current HEAD. When built with enable_debug=no, the parameter output expected at --verb 4 is not printed due to use of #ifdef ENABLE_DEBUG in the responsible code sections. This appears to be a mistake when looking at the configure help text for enable_small and enable_debug. This change keys the relevant code off of enable_small instead, including the parameter listing when enale_small=no (the configure-script default.) Most of this code is in options.c, with some callers present in plugin.c/h and route.c/h. No function code is changed, just the #ifdef values to use the small feature instead of debug. This means builds no longer need enable_debug=yes in order to get the expected log output at verb 4. -- Josh 

This patch allows one to specify --pkcs11-id auto to automatically select the first certificate on a pkcs11 device. This simplifies scripts and usage in environments where clients may only use a single certificate for connecting to a VPN. Based on a patch by Oliver Dumschat-Hötte. Reported-by: Oliver Dumschat-Hötte <o.d...@tr...> Signed-off-by: Chris J Arges <chr...@ca...> --- src/openvpn/pkcs11.c | 41 +++++++++++++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/src/openvpn/pkcs11.c b/src/openvpn/pkcs11.c index 3a15ef6..11d5e8f 100644 --- a/src/openvpn/pkcs11.c +++ b/src/openvpn/pkcs11.c @@ -669,14 +669,39 @@ tls_ctx_use_pkcs11 (	}	}	else { -	if ( -	(rv = pkcs11h_certificate_deserializeCertificateId ( -	&certificate_id, -	pkcs11_id -	)) != CKR_OK -	) { -	msg (M_WARN, "PKCS#11: Cannot deserialize id %ld-'%s'", rv, pkcs11h_getMessage (rv)); -	goto cleanup; +	if ( strcmp(pkcs11_id, "auto") == 0 ) { +	char *pkcs11_id_read = NULL; +	char *base64 = NULL; +	if ( !pkcs11_management_id_get( + 0, + &pkcs11_id_read, + &base64 + ) +	) { +	msg (M_WARN, "PKCS#11: pkcs11_management_id_get 0 failed"); +	goto cleanup; +	} +	if ( +	(rv = pkcs11h_certificate_deserializeCertificateId ( +	&certificate_id, +	pkcs11_id_read +	)) != CKR_OK +	) { +	msg (M_WARN, "PKCS#11: Cannot deserialize auto id %ld-'%s'", rv, + pkcs11h_getMessage (rv)); +	goto cleanup; +	} +	} else { +	if ( +	(rv = pkcs11h_certificate_deserializeCertificateId ( +	&certificate_id, +	pkcs11_id +	)) != CKR_OK +	) { +	msg (M_WARN, "PKCS#11: Cannot deserialize id %ld-'%s'", rv, + pkcs11h_getMessage (rv)); +	goto cleanup; +	}	}	} -- 1.7.9.5 

Hi, On Thursday 14 February 2013 11:52:33 David Sommerseth wrote: > This is just a minor issue which has been annoying me a little bit. > I've attached a patch which ensures that the --tls-remote semantic > warning is only printed once. > > However, I wonder how useful that warning really is these days. Do > we really need that warning? The warning comes from this commit [1]: I just removed this warning while working on the --tls-remote compat / depreciation patchset. So, don't bother sending a patch of your own. I'll post the patchset next week after some testing. Heiko -- Heiko Hund | Sr. Software Engineer | Tel +49-721-25516-237 | Fax -200 SOPHOS NSG | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany 

OpenVPN 2.3.0 Windows installer version I004 has been released. It includes a number of fixes compared to the previous one (I001): - Uses OpenSSL 1.0.1e that includes a proper fix for CVE-2013-0169[1] - Fixes broken silent installations[2] - Installs TAP utilities by default[3] - Fixes broken man-page link in the Start menu - Adds and updates other Start menu documentation links You can download the new installer from here: <http://openvpn.net/index.php/download/community-downloads.html> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0169> [2] <https://community.openvpn.net/openvpn/ticket/249> [3] <https://community.openvpn.net/openvpn/ticket/255> 

A minor correction... the installers of course contain OpenSSL 1.0.1e, not 1.0.0e. Samuli > Hi all, > > I rebuilt the OpenVPN 2.3.0 Windows installer using OpenSSL 1.0.0e: > > <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I001_master-i686.exe> > <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I001_master-x86_64.exe> > > OpenSSL 1.0.0e fixes the security hole that was discussed earlier on the > openvpn-user mailing list: > > <http://thread.gmane.org/gmane.network.openvpn.user/33859> > <http://thread.gmane.org/gmane.network.openvpn.user/33867> > > The installers also incorporate two fixes related to the installer itself: > > <https://community.openvpn.net/openvpn/ticket/249> > <https://community.openvpn.net/openvpn/ticket/255> > > I ran the basic smoketests on WinXP 32-bit and Win7 64-bit and > everything seemed to work as intended. Please test the installers if you > can: I'll try to get them released tomorrow. > > Best regards, > 

Hi, Two of the Windows help files are generated dynamically from within openvpn-build/windows-nsis/openvpn.nsi: FileOpen $R0 "$INSTDIR\config\README.txt" w FileWrite $R0 "This directory should contain ${PACKAGE_NAME} configuration files$\r$\n" FileWrite $R0 "each having an extension of .${OPENVPN_CONFIG_EXT}$\r$\n" FileWrite $R0 "$\r$\n" FileWrite $R0 "When ${PACKAGE_NAME} is started as a service, a separate ${PACKAGE_NAME}$\r$\n" FileWrite $R0 "process will be instantiated for each configuration file.$\r$\n" FileClose $R0 --- snip --- FileOpen $R0 "$INSTDIR\log\README.txt" w FileWrite $R0 "This directory will contain the log files for ${PACKAGE_NAME}$\r$\n" FileWrite $R0 "sessions which are being run as a service.$\r$\n" FileClose $R0 I don't particularly like this approach - primarily because it hides part of the OpenVPN documentation inside an installer script. It also makes it harder to maintain a localized versions of the documentation, and there could be issues with non-ascii characters. Anyways, I think these help files are semi-useful at best, a bit like the "tls-remote" warning. I think we could safely move their contents to openvpn/INSTALL-win32.txt, or put them into static files under openvpn/doc. Any opinions? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Am 14.02.13 11:52, schrieb David Sommerseth: > Hi, > > This is just a minor issue which has been annoying me a little bit. > I've attached a patch which ensures that the --tls-remote semantic > warning is only printed once. > > However, I wonder how useful that warning really is these days. Do > we really need that warning? The warning comes from this commit [1]: > > commit c04bc0223c9b17f203555b933cbeedbf3b343c0e > Author: james <james@e7ae566f-a301-0410-adde-c780ea21d3b5> > Date: Sun Jul 27 18:20:52 2008 +0000 > > Added additional warnings for: > > * --tls-remote -- some people misunderstand the semantics > > * --script-security -- warn if script-security will allow user-defined > scripts to be called, and also warn separately if passwords may be > passed to scripts via the environment > > It's from 2008. I see that in some cases this warning is needed, but I > also think people need to read the man pages when things doesn't work as > expected. Not that we need to hand-hold people the whole way through. > > If we find that all of these warnings are not that useful any more, I'd > rather suggest that we revert the commit above. Otherwise we can also > consider to just remove the --tls-remote warning completely. > > Any thoughts? > > I think we can remove the script-security warnings completely. I never found the --tls-remote useful either. Arne 

I don't think these warnings are all that useful. People who don't have the common sense to read the man-page are probably in trouble anyways. I'd say revert the patch. Samuli > Hi, > > This is just a minor issue which has been annoying me a little bit. > I've attached a patch which ensures that the --tls-remote semantic > warning is only printed once. > > However, I wonder how useful that warning really is these days. Do > we really need that warning? The warning comes from this commit [1]: > > commit c04bc0223c9b17f203555b933cbeedbf3b343c0e > Author: james <james@e7ae566f-a301-0410-adde-c780ea21d3b5> > Date: Sun Jul 27 18:20:52 2008 +0000 > > Added additional warnings for: > > * --tls-remote -- some people misunderstand the semantics > > * --script-security -- warn if script-security will allow user-defined > scripts to be called, and also warn separately if passwords may be > passed to scripts via the environment > > It's from 2008. I see that in some cases this warning is needed, but I > also think people need to read the man pages when things doesn't work as > expected. Not that we need to hand-hold people the whole way through. > > If we find that all of these warnings are not that useful any more, I'd > rather suggest that we revert the commit above. Otherwise we can also > consider to just remove the --tls-remote warning completely. > > Any thoughts? > > > [1] <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff; > h=c04bc0223c9b17f203555b933cbeedbf3b343c0e> > > 

 Hi, This is just a minor issue which has been annoying me a little bit. I've attached a patch which ensures that the --tls-remote semantic warning is only printed once. However, I wonder how useful that warning really is these days. Do we really need that warning? The warning comes from this commit [1]: commit c04bc0223c9b17f203555b933cbeedbf3b343c0e Author: james <james@e7ae566f-a301-0410-adde-c780ea21d3b5> Date: Sun Jul 27 18:20:52 2008 +0000 Added additional warnings for: * --tls-remote -- some people misunderstand the semantics * --script-security -- warn if script-security will allow user-defined scripts to be called, and also warn separately if passwords may be passed to scripts via the environment It's from 2008. I see that in some cases this warning is needed, but I also think people need to read the man pages when things doesn't work as expected. Not that we need to hand-hold people the whole way through. If we find that all of these warnings are not that useful any more, I'd rather suggest that we revert the commit above. Otherwise we can also consider to just remove the --tls-remote warning completely. Any thoughts? [1] <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff; h=c04bc0223c9b17f203555b933cbeedbf3b343c0e> -- kind regards, David Sommerseth 

Hi all, I rebuilt the OpenVPN 2.3.0 Windows installer using OpenSSL 1.0.0e: <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I001_master-i686.exe> <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I001_master-x86_64.exe> OpenSSL 1.0.0e fixes the security hole that was discussed earlier on the openvpn-user mailing list: <http://thread.gmane.org/gmane.network.openvpn.user/33859> <http://thread.gmane.org/gmane.network.openvpn.user/33867> The installers also incorporate two fixes related to the installer itself: <https://community.openvpn.net/openvpn/ticket/249> <https://community.openvpn.net/openvpn/ticket/255> I ran the basic smoketests on WinXP 32-bit and Win7 64-bit and everything seemed to work as intended. Please test the installers if you can: I'll try to get them released tomorrow. Best regards, -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi all, Here are updated Windows installers for 2.3.0: <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I000_master-i686.exe> <http://build.openvpn.net/downloads/temp/openvpn-install-2.3.0-I000_master-x86_64.exe> These installers fix two bugs: <https://community.openvpn.net/openvpn/ticket/249> <https://community.openvpn.net/openvpn/ticket/255> I've tested the installers on WinXP 32-bit and Win7 64-bit and the problems seem to be gone. Please test so that we can push out another 2.3.0 Windows build a.s.a.p. Thanks, -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock PS. I got one further tapinstall.exe fix in the queue: <https://community.openvpn.net/openvpn/ticket/153> 

I recently set up a 2nd openvpn instance using --shaper. With a sufficiently high value, it seems to do nothing; with any lower value, it makes the tunnel unusable, transferring roughly one packet per second. (My threshold was not low, I'm talking about handsful of kB/s). I tested openvpn 2.0.9, where shaper worked well. I was able to get openvpn 2.3 working with shaper by replacing openvpn_gettimeofday with gettimeofday in shaper.h in two places. I don't understand the intent of the logic in update_now (called by update_now_usec->update_time->openvpn_gettimeofday). Could someone who does look at how it interacts with shaper ?? Justin 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgot to add this was also applied to release/2.3 commit a8fe779b04cc5bf698a1bf5bed4b0189126c3a38 On 06/02/13 20:04, David Sommerseth wrote: > Your patch has been applied to the master branch. > > commit 6e6f55f4ba5deda5649679a13e4e323e07b3e661 Author: Heiko Hund > Date: Mon Feb 4 11:39:25 2013 +0000 > > Ignore UTF-8 byte order mark > > Signed-off-by: Heiko Hund <hei...@so...> Acked-by: David > Sommerseth <da...@re...> Message-Id: > 135...@so... URL: > http://article.gmane.org/gmane.network.openvpn.devel/7342 > Signed-off-by: David Sommerseth <da...@re...> > - -- kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlESqzAACgkQDC186MBRfrrKygCfTqg7qDJDo/f0rlKln8Qi4bbJ 2yIAoJeuU9Wt2GSrKGDHgbi0FFIZ2TZQ =PUer -----END PGP SIGNATURE----- 

Your patch has been applied to the master branch. commit 6e6f55f4ba5deda5649679a13e4e323e07b3e661 Author: Heiko Hund Date: Mon Feb 4 11:39:25 2013 +0000 Ignore UTF-8 byte order mark Signed-off-by: Heiko Hund <hei...@so...> Acked-by: David Sommerseth <da...@re...> Message-Id: 135...@so... URL: http://article.gmane.org/gmane.network.openvpn.devel/7342 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

> -----Original Message----- > From: David Sommerseth [mailto:ope...@to...] > Sent: dinsdag 5 februari 2013 16:00 > To: Adriaan de Jong > Cc: ope...@li...; Jan Just Keijser; James Yonan > Subject: Re: [Openvpn-devel] option --crl-verify PATH dir > > On 04/02/13 08:43, Adriaan de Jong wrote: > >> -----Original Message----- > >> From: David Sommerseth [mailto:ope...@to...] > >> Sent: zondag 3 februari 2013 15:52 > >> To: Jan Just Keijser > >> Cc: ope...@li... > >> Subject: Re: [Openvpn-devel] option --crl-verify PATH dir > >> > >> On 03/02/13 12:02, Jan Just Keijser wrote: > >>> hi, > >>> > >>> what is the second option to '--crl-verify' supposed to do? in > >>> options.c it sets a flag SSLF_CRL_VERIFY_DIR which then triggers > the > >>> function 'verify_check_crl_dir'. However, this function does not > >>> seem to do anything.... > >> > >> Quickly looked at the code ... with the 'dir' flag (which sets > >> SSLF_CRL_VERIFY_DIR), it's no longer a typical CRL file validation. > >> If you create (touch) a file in the defined directory with the file > >> name matching a particular client's serial number; the connection > >> will be denied. > >> > > > > Confirmed, with the footnote that this is a weird way of going about > things. > > > > I would like to suggest deprecating this option from 2.4 (or 2.3.1?) > onwards, and forcing people to either: > > > > - Create an actual CRL file. This is not difficult. In general, > people using OpenVPN should be managing their own CA in the OpenVPN > world. > > - Failing that, create a custom script to do this. > > > > I'm always open for discussion, but imho this should not be core > functionality in OpenVPN. > > I agree that this directory based "CRL" with empty files shouldn't be a > core part of OpenVPN. This is in my eyes what --tls-verify scripts is > supposed to solve. I also agree with JJK, that implementing proper CA > path support makes a lot of sense. Even though PolarSSL lacks this > support now, I believe Paul wouldn't instantly object a patch > implementing a CA path support. > > However, I'm not sure it's a good idea to remove this feature in 2.4 or > earlier. There are people depending on this feature. And it touches > the same discussion topic we had at FOSDEM regarding --compat-names and > --no-name-remapping. > > If removed, I would say it should be removed in OpenVPN 3. We can > start warning about it in 2.4. However, I'd really like to have James > feedback on this as well before we just decide to kill it off at a > later release. Just because I want to avoid the same > situation/discussion as we had at FOSDEM. > I agree, that's why I suggested deprecation of this feature. We could even provide an example script that performs the same functionality. About JJK's issue, I'm not sure whether Paul has support for loading all CRLs in a directory planned, but it should be a small patch now that crt loading exists. As an aside, I'm working on a patch that moves CRL verification from OpenVPN into the SSL library (where it should be). Expect that within a few days. Adriaan 

On 04/02/13 08:43, Adriaan de Jong wrote: >> -----Original Message----- >> From: David Sommerseth [mailto:ope...@to...] >> Sent: zondag 3 februari 2013 15:52 >> To: Jan Just Keijser >> Cc: ope...@li... >> Subject: Re: [Openvpn-devel] option --crl-verify PATH dir >> >> On 03/02/13 12:02, Jan Just Keijser wrote: >>> hi, >>> >>> what is the second option to '--crl-verify' supposed to do? in >>> options.c it sets a flag SSLF_CRL_VERIFY_DIR which then triggers the >>> function 'verify_check_crl_dir'. However, this function does not seem >>> to do anything.... >> >> Quickly looked at the code ... with the 'dir' flag (which sets >> SSLF_CRL_VERIFY_DIR), it's no longer a typical CRL file validation. If >> you create (touch) a file in the defined directory with the file name >> matching a particular client's serial number; the connection will be >> denied. >> > > Confirmed, with the footnote that this is a weird way of going about things. > > I would like to suggest deprecating this option from 2.4 (or 2.3.1?) onwards, and forcing people to either: > > - Create an actual CRL file. This is not difficult. In general, people using OpenVPN should be managing their own CA in the OpenVPN world. > - Failing that, create a custom script to do this. > > I'm always open for discussion, but imho this should not be core functionality in OpenVPN. I agree that this directory based "CRL" with empty files shouldn't be a core part of OpenVPN. This is in my eyes what --tls-verify scripts is supposed to solve. I also agree with JJK, that implementing proper CA path support makes a lot of sense. Even though PolarSSL lacks this support now, I believe Paul wouldn't instantly object a patch implementing a CA path support. However, I'm not sure it's a good idea to remove this feature in 2.4 or earlier. There are people depending on this feature. And it touches the same discussion topic we had at FOSDEM regarding --compat-names and --no-name-remapping. If removed, I would say it should be removed in OpenVPN 3. We can start warning about it in 2.4. However, I'd really like to have James feedback on this as well before we just decide to kill it off at a later release. Just because I want to avoid the same situation/discussion as we had at FOSDEM. -- kind regards, David Sommerseth 

I think this option should remain. This is useful for temporarily disabling users for VPNs that don't incorporate user/pass authentication. I am opposed to deprecating this function. ----- Eric F Crist On Feb 4, 2013, at 01:43:10, Adriaan de Jong <de...@fo...> wrote: >> -----Original Message----- >> From: David Sommerseth [mailto:ope...@to...] >> Sent: zondag 3 februari 2013 15:52 >> To: Jan Just Keijser >> Cc: ope...@li... >> Subject: Re: [Openvpn-devel] option --crl-verify PATH dir >> >> On 03/02/13 12:02, Jan Just Keijser wrote: >>> hi, >>> >>> what is the second option to '--crl-verify' supposed to do? in >>> options.c it sets a flag SSLF_CRL_VERIFY_DIR which then triggers the >>> function 'verify_check_crl_dir'. However, this function does not seem >>> to do anything.... >> >> Quickly looked at the code ... with the 'dir' flag (which sets >> SSLF_CRL_VERIFY_DIR), it's no longer a typical CRL file validation. If >> you create (touch) a file in the defined directory with the file name >> matching a particular client's serial number; the connection will be >> denied. >> > > Confirmed, with the footnote that this is a weird way of going about things. > > I would like to suggest deprecating this option from 2.4 (or 2.3.1?) onwards, and forcing people to either: > > - Create an actual CRL file. This is not difficult. In general, people using OpenVPN should be managing their own CA in the OpenVPN world. > - Failing that, create a custom script to do this. > > I'm always open for discussion, but imho this should not be core functionality in OpenVPN. > > Kind regards, > Adriaan > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel