Warn user if their certificate has expired

PATCH In review Steffan Karger 5 participants 18 messages Dec 14, 2015 – Jan 2, 2016

Share & tools

Steffan Karger

author

2015-12-14 20:09 UTC #0 lore raw

PATCH 1/1 Warn user if their certificate has expired

Previously, client certificate expiry warnings would only visible in the server log, and server certificate expiry warnings in the client log. Both after a (failed) connection attempt. This patch adds a warning to log when a users own certificate has expired (or is not yet valid) to ease problem diagnosis / error reporting.

Note that this is just a warning, since on some systems (notably embedded devices) there might be no correct time available.

Signed-off-by Steffan Karger <[email protected]...>

---
 src/openvpn/ssl.c          |  3 +++
 src/openvpn/ssl_backend.h  |  9 +++++++++
 src/openvpn/ssl_openssl.c  | 27 +++++++++++++++++++++++++++
 src/openvpn/ssl_polarssl.c | 14 ++++++++++++++
 4 files changed, 53 insertions(+)

src/openvpn/ssl.c +3 -0

index 887bd75..665fdd7 100644
@@ -566,6 +566,9 @@ init_ssl (const struct options *options, struct tls_root_ctx *new_ctx)
       tls_ctx_load_extra_certs(new_ctx, options->extra_certs_file, options->extra_certs_file_inline);
     }
 
+  /* Check certificate notBefore and notAfter */
+  tls_ctx_check_cert_time(new_ctx);
+
   /* Once keys and cert are loaded, load ECDH parameters */
   if (options->tls_server)
     tls_ctx_load_ecdh_params(new_ctx, options->ecdh_curve);

src/openvpn/ssl_backend.h +9 -0

index 99930e5..ac28f5f 100644
@@ -175,6 +175,15 @@ void tls_ctx_set_options (struct tls_root_ctx *ctx, unsigned int ssl_flags);
 void tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers);
 
 /**
+ * Check our certificate notBefore and notAfter fields, and warn if the cert is
+ * either not yet valid or has expired.  Note that this is a non-fatal error,
+ * since we compare against the system time, which might be incorrect.
+ *
+ * @param ctx		TLS context to get our certificate from.
+ */
+void tls_ctx_check_cert_time (const struct tls_root_ctx *ctx);
+
+/**
  * Load Diffie Hellman Parameters, and load them into the library-specific
  * TLS context.
  *

src/openvpn/ssl_openssl.c +27 -0

index 4430fec..2b74818 100644
@@ -351,6 +351,33 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers)
 }
 
 void
+tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
+{
+  int ret;
+  const X509 *cert = SSL_CTX_get0_certificate(ctx->ctx);
+
+  ret = X509_cmp_time (X509_get_notBefore (cert), NULL);
+  if (ret == 0)
+    {
+      msg (D_TLS_DEBUG_MED, "Failed to read certificate notBefore field.");
+    }
+  if (ret > 0)
+    {
+      msg (M_WARN, "WARNING: Your certificate is not yet valid!");
+    }
+
+  ret = X509_cmp_time (X509_get_notAfter (cert), NULL);
+  if (ret == 0)
+    {
+      msg (D_TLS_DEBUG_MED, "Failed to read certificate notAfter field.");
+    }
+  if (ret < 0)
+    {
+      msg (M_WARN, "WARNING: Your certificate has expired!");
+    }
+}
+
+void
 tls_ctx_load_dh_params (struct tls_root_ctx *ctx, const char *dh_file,
     const char *dh_file_inline
     )

src/openvpn/ssl_polarssl.c +14 -0

index bb58746..4782469 100644
@@ -217,6 +217,20 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers)
 }
 
 void
+tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
+{
+  if (x509_time_future (&ctx->crt_chain->valid_from))
+    {
+      msg (M_WARN, "WARNING: Your certificate is not yet valid!");
+    }
+
+  if (x509_time_expired (&ctx->crt_chain->valid_to))
+    {
+      msg (M_WARN, "WARNING: Your certificate has expired!");
+    }
+}
+
+void
 tls_ctx_load_dh_params (struct tls_root_ctx *ctx, const char *dh_file,
     const char *dh_inline
     )

Signature · 1 line

2.5.0

Gert Doering

2015-12-14 20:45 UTC #1 lore raw

ACK! WANT!

(Tested with an expired certificate and it works, and looking at OpenSSL x509_vfy.c and PolarSSL x509_8h, I'm reasonable confident that it will also for for not-yet-valid certificates and that we call this all correctly)

Your patch has been applied to the master branch (release/2.3 coming when that has migrated to PolarSSL 1.3).

commit 091edd8e2996867447eeb665af957547aa8b3107 (master)

Author: Steffan Karger
Date:   Mon Dec 14 21:09:18 2015 +0100

     Warn user if their certificate has expired

     Signed-off-by: Steffan Karger <[email protected]...>
     Acked-by: Gert Doering <[email protected]...>
     Message-Id: <[email protected]...>
     URL: http://article.gmane.org/gmane.network.openvpn.devel/10794
     Signed-off-by: Gert Doering <[email protected]...>

--
kind regards,

Gert Doering

David Sommerseth

2015-12-15 00:12 UTC #2 lore raw

In reply to Steffan Karger

Quoted 21 lines · Steffan Karger

Previously, client certificate expiry warnings would only visible in the server log, and server certificate expiry warnings in the client log. Both after a (failed) connection attempt. This patch adds a warning to log when a users own certificate has expired (or is not yet valid) to ease problem diagnosis / error reporting.
Note that this is just a warning, since on some systems (notably embedded devices) there might be no correct time available.
Signed-off-by Steffan Karger <[email protected]...>
---
 src/openvpn/ssl.c          |  3 +++
 src/openvpn/ssl_backend.h  |  9 +++++++++
 src/openvpn/ssl_openssl.c  | 27 +++++++++++++++++++++++++++
 src/openvpn/ssl_polarssl.c | 14 ++++++++++++++
 4 files changed, 53 insertions(+)
src/openvpn/ssl.c +0 -0
index 887bd75..665fdd7 100644

[...snip...]

src/openvpn/ssl.c

Quoted 6 lines

void

src/openvpn/ssl.c +4 -0

+tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
+{
+  int ret;
+  const X509 *cert = SSL_CTX_get0_certificate(ctx->ctx);

Hi,

Just tried to build openvpn on one of my laptops (Scientific Linux 7.1, openssl-1.0.1e-42.el7). And it explodes when reaching the SSL_CTX_get0_certificate(), it seems that support arrived in OpenSSL 1.0.2? Could that be right? Haven't had brainpower yet to dig deeper.

I will retry a build on my work laptop too (RHEL 7.2) tomorrow, to see if this is an issue there too.

Signature · 8 lines

kind regards,

David Sommerseth

-- 
kind regards,

David Sommerseth

Gert Doering

2015-12-15 07:53 UTC #3 lore raw

Hi,

Quoted 4 lines · David Sommerseth

Just tried to build openvpn on one of my laptops (Scientific Linux 7.1, openssl-1.0.1e-42.el7). And it explodes when reaching the SSL_CTX_get0_certificate(), it seems that support arrived in OpenSSL 1.0.2? Could that be right? Haven't had brainpower yet to dig deeper.

Yeah, we noticed. Sorry for that. Never seen so much red on the buildbot list before... :-)

Committed and pushed the "not before 1.0.2" workaround.

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Jan Just Keijser

2015-12-15 21:41 UTC #4 lore raw

Hi,

Quoted 13 lines · Gert Doering

Hi,
Quoted 4 lines · David Sommerseth
Just tried to build openvpn on one of my laptops (Scientific Linux 7.1, openssl-1.0.1e-42.el7). And it explodes when reaching the SSL_CTX_get0_certificate(), it seems that support arrived in OpenSSL 1.0.2? Could that be right? Haven't had brainpower yet to dig deeper.
Yeah, we noticed. Sorry for that. Never seen so much red on the buildbot list before... :-)
Committed and pushed the "not before 1.0.2" workaround.

hmmmm I think this feature is actually worth adding to systems based on OpenSSL 1.0.1 as well (think RHEL 7 etc). The problem is, the current fix is very 1.0.2 specific and there seems to be no easy work-around. Another approach is to check the certificate expiry time when the cert is loaded, but - as Steffan pointed out - this would mean that multiple places need a function call to check this:
- when loading an x509 file
- when loading a pkcs12 file
- when loading an inline blob
- when loading something from pkcs11
- when loading something via cryptostore
- when loading something using the management interface

the problem lies in the 'reachability' of the actual X509 certificate structure in OpenSSL
- the SSL_CTX context contains the X509 cert, but you cannot get at it until 1.0.2
- at connection time the SSL struct also contains it, but this is too late in the process.

I'm inclined to alter the patch to check it at all items listed above - what do you guys think?
Having to wait for openssl 1.0.2 (which even my fedora 22 box does not yet have) seems a bit like "so close, yet so far ..."

JJK

Steffan Karger

author

2015-12-15 22:15 UTC #5 lore raw

Quoted 32 lines · Jan Just Keijser

Quoted 11 lines · Gert Doering
Quoted 4 lines · David Sommerseth
Just tried to build openvpn on one of my laptops (Scientific Linux 7.1, openssl-1.0.1e-42.el7). And it explodes when reaching the SSL_CTX_get0_certificate(), it seems that support arrived in OpenSSL 1.0.2? Could that be right? Haven't had brainpower yet to dig deeper.
Yeah, we noticed. Sorry for that. Never seen so much red on the buildbot list before... :-)
Committed and pushed the "not before 1.0.2" workaround.
hmmmm I think this feature is actually worth adding to systems based on OpenSSL 1.0.1 as well (think RHEL 7 etc). The problem is, the current fix is very 1.0.2 specific and there seems to be no easy work-around. Another approach is to check the certificate expiry time when the cert is loaded, but - as Steffan pointed out - this would mean that multiple places need a function call to check this:
- when loading an x509 file
- when loading a pkcs12 file
- when loading an inline blob
- when loading something from pkcs11
- when loading something via cryptostore
- when loading something using the management interface
the problem lies in the 'reachability' of the actual X509 certificate structure in OpenSSL
- the SSL_CTX context contains the X509 cert, but you cannot get at it until 1.0.2
- at connection time the SSL struct also contains it, but this is too late in the process.

Quoted 4 lines

I'm inclined to alter the patch to check it at all items listed above - what do you guys think?
Having to wait for openssl 1.0.2 (which even my fedora 22 box does not yet have) seems a bit like "so close, yet so far ..."

Just use mbedtls ;-)

OpenSSL 1.0.2 has been released almost a year ago, so upcoming distro releases will probably contain 1.0.2+ (e.g. Ubuntu 15.10 already has it, 16.04 LTS will have it too). Should not take too long, right?

As you've probably noticed in the other thread, I don't particularly like the idea of adding that extra code. But I won't actively oppose such a patch either.

-Steffan

Jan Just Keijser

2015-12-23 15:11 UTC #6 lore raw

Hi,

Quoted 11 lines · Steffan Karger

[...]
Just use mbedtls ;-)
OpenSSL 1.0.2 has been released almost a year ago, so upcoming distro releases will probably contain 1.0.2+ (e.g. Ubuntu 15.10 already has it, 16.04 LTS will have it too). Should not take too long, right?
As you've probably noticed in the other thread, I don't particularly like the idea of adding that extra code. But I won't actively oppose such a patch either.

I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)

happy holidays,

JJK

src/openvpn/ssl_openssl.c +35 -0

@@ -335,6 +335,41 @@
 }
 
 void
+tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
+{
+  int ret;
+  const X509 *cert;
+#if OPENSSL_VERSION_NUMBER >= 0x10002000L
+  cert = SSL_CTX_get0_certificate(ctx->ctx);
+#else
+/* OpenSSL 1.0.1 and earlier need an SSL object to get at the certificate */
+  SSL *ssl = SSL_new(ctx->ctx);
+  cert = SSL_get_certificate(ssl);
+  SSL_free(ssl);
+#endif
+
+  ret = X509_cmp_time (X509_get_notBefore (cert), NULL);
+  if (ret == 0)
+    {
+      msg (D_TLS_DEBUG_MED, "Failed to read certificate notBefore field.");
+    }
+  if (ret > 0)
+    {
+      msg (M_WARN, "WARNING: Your certificate is not yet valid!");
+    }
+
+  ret = X509_cmp_time (X509_get_notAfter (cert), NULL);
+  if (ret == 0)
+    {
+      msg (D_TLS_DEBUG_MED, "Failed to read certificate notAfter field.");
+    }
+  if (ret < 0)
+    {
+      msg (M_WARN, "WARNING: Your certificate has expired!");
+    }
+}
+
+void
 tls_ctx_load_dh_params (struct tls_root_ctx *ctx, const char *dh_file,
     const char *dh_file_inline
     )

Steffan Karger

author

2015-12-23 16:26 UTC #7 lore raw

Hi,

Quoted 13 lines · Jan Just Keijser

Quoted 11 lines · Steffan Karger
[...]
Just use mbedtls ;-)
OpenSSL 1.0.2 has been released almost a year ago, so upcoming distro releases will probably contain 1.0.2+ (e.g. Ubuntu 15.10 already has it, 16.04 LTS will have it too). Should not take too long, right?
As you've probably noticed in the other thread, I don't particularly like the idea of adding that extra code. But I won't actively oppose such a patch either.

Quoted 5 lines

I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)

This looks very promising! Thanks. Do you have any clue if this will work on pre-1.0.1 too? (If not, I can test, but if you do, I can save myself the trouble.)

-Steffan

Jan Just Keijser

2015-12-23 16:46 UTC #8 lore raw

Hi,

Quoted 24 lines · Steffan Karger

Hi,
Quoted 13 lines · Jan Just Keijser
Quoted 11 lines · Steffan Karger
[...]
Just use mbedtls ;-)
OpenSSL 1.0.2 has been released almost a year ago, so upcoming distro releases will probably contain 1.0.2+ (e.g. Ubuntu 15.10 already has it, 16.04 LTS will have it too). Should not take too long, right?
As you've probably noticed in the other thread, I don't particularly like the idea of adding that extra code. But I won't actively oppose such a patch either.
Quoted 6 lines
I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)

Quoted 4 lines

This looks very promising! Thanks. Do you have any clue if this will work on pre-1.0.1 too? (If not, I can test, but if you do, I can save myself the trouble.)

works on CentOS 5 too:
Wed Dec 23 17:44:40 2015 OpenVPN 2.3.9 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 23 2015 Wed Dec 23 17:44:40 2015 library versions: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, LZO 2.06
Wed Dec 23 17:44:40 2015 WARNING: Your certificate has expired!

however, I just realized there's a memory leak in my patch: I do an "SSL_free(ssl)" and then access the X509 cert - this X509 cert struct is (possibly) freed by the SSL_free() call . I/we should split the patch so that the SSL_free is done after all access to the X509 struct are done.

HTH,

JJK

Gert Doering

2015-12-26 09:19 UTC #9 lore raw

In reply to Jan Just Keijser

Hi,

Quoted 5 lines · Jan Just Keijser

I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)

Great discovery :-) - and it nicely works for me:

Sat Dec 26 10:11:14 2015 OpenVPN 2.3_git [git:ssl-expire/0f7319906a9dff58+] amd64-unknown-freebsd7.4 [SSL (OpenSSL)] [LZO] [LZ4] [MH] [IPv6] built on Dec 26 2015 Sat Dec 26 10:11:14 2015 library versions: OpenSSL 0.9.8q 2 Dec 2010, LZO 2.04
Sat Dec 26 10:11:16 2015 WARNING: Your certificate has expired!

this is about as old as it gets - thanks a lot. Mogrified into a patch against git master with the SSL_free() moved to the right place attached below, for Steffan to ACK.

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

From cc94bfe47840f3b4815e3ab1f0b65267d992bd08 Mon Sep 17 00:00:00 2001
From: Jan Just Keijser <[email protected]...>
Date: Sat, 26 Dec 2015 10:15:04 +0100
Subject: [PATCH] Make certificate expiry warning patch (091edd8e299686) work on OpenSSL 1.0.1 and earlier.

Integrating feedback from Steffan Karger, tested by Gert Doering on FreeBSD 7.4 / OpenSSL 0.9.8.

Signed-off-by Gert Doering <[email protected]...>

---
 src/openvpn/ssl_openssl.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

src/openvpn/ssl_openssl.c +12 -2

index 4792b08..0a7f14b 100644
@@ -353,9 +353,17 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers)
 void
 tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
 {
-#if OPENSSL_VERSION_NUMBER >= 0x10002000L
   int ret;
-  const X509 *cert = SSL_CTX_get0_certificate(ctx->ctx);
+  const X509 *cert;
+
+#if OPENSSL_VERSION_NUMBER >= 0x10002000L
+  /* OpenSSL 1.0.2 and up */
+  cert = SSL_CTX_get0_certificate(ctx->ctx);
+#else
+  /* OpenSSL 1.0.1 and earlier need an SSL object to get at the certificate */
+  SSL *ssl = SSL_new(ctx->ctx);
+  cert = SSL_get_certificate(ssl);
+#endif
 
   ret = X509_cmp_time (X509_get_notBefore (cert), NULL);
   if (ret == 0)

@@ -376,6 +384,8 @@ tls_ctx_check_cert_time (const struct tls_root_ctx *ctx)
     {
       msg (M_WARN, "WARNING: Your certificate has expired!");
     }
+#if OPENSSL_VERSION_NUMBER < 0x10002000L
+  SSL_free(ssl);
 #endif
 }

Signature · 1 line

1.7.3.5

Steffan Karger

author

2015-12-26 09:40 UTC #10 lore raw

Quoted 9 lines · Gert Doering

Quoted 5 lines · Jan Just Keijser
I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)
Great discovery :-) - and it nicely works for me:

Quoted 7 lines

Sat Dec 26 10:11:14 2015 OpenVPN 2.3_git [git:ssl-expire/0f7319906a9dff58+] amd64-unknown-freebsd7.4 [SSL (OpenSSL)] [LZO] [LZ4] [MH] [IPv6] built on Dec 26 2015 Sat Dec 26 10:11:14 2015 library versions: OpenSSL 0.9.8q 2 Dec 2010, LZO 2.04
Sat Dec 26 10:11:16 2015 WARNING: Your certificate has expired!
this is about as old as it gets - thanks a lot. Mogrified into a patch against git master with the SSL_free() moved to the right place attached below, for Steffan to ACK.

ACK, much wanted functionality and code looks good.

-Steffan

Илья Шипицин

2016-01-02 18:11 UTC #11 lore raw

I'm getting "segmentation fault" after that commit.
well, I suspect you beleive that user _always_ has client cert, which is not true.

obviously, for preshared keys there''s no user cert, and for user/password auth there's also no user cert (which is our case)

is Valgrind I see the following:

https://community.openvpn.net/openvpn/ticket/644#ticket

==19381== Invalid read of size 8

==19381==    at 0x487454: tls_ctx_check_cert_time (ssl_openssl.c:368)
==19381==    by 0x47F619: init_ssl (ssl.c:571)
==19381==    by 0x420F45: do_init_crypto_tls_c1 (init.c:2160)
==19381==    by 0x4211F6: do_init_crypto_tls (init.c:2240)
==19381==    by 0x42197B: do_init_crypto (init.c:2428)
==19381==    by 0x423C92: init_instance (init.c:3550)
==19381==    by 0x423855: init_instance_handle_signals (init.c:3405)
==19381==    by 0x443788: tunnel_point_to_point (openvpn.c:70)
==19381==    by 0x443BAD: openvpn_main (openvpn.c:270)
==19381==    by 0x443CC0: main (openvpn.c:345)

==19381== Address 0x0 is not stack'd, malloc'd or (recently) free'd

does that mean "I'm trying to read a cert which does not exist" ?

I investigated, I'm getting crash dumps since
https://github.com/OpenVPN/openvpn/commit/091edd8e2996867447eeb665af957547aa8b3107

can you please fix that before 2.3.10 ?

2015-12-26 12:40 GMT+03:00 Steffan Karger <[email protected]...>:

Quoted 32 lines · Gert Doering

Quoted 10 lines · Jan Just Keijser
Quoted 5 lines
I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)
Great discovery :-) - and it nicely works for me:
Sat Dec 26 10:11:14 2015 OpenVPN 2.3_git
[git:ssl-expire/0f7319906a9dff58+] amd64-unknown-freebsd7.4 [SSL (OpenSSL)] [LZO] [LZ4] [MH] [IPv6] built on Dec 26 2015
Quoted 1 line
Sat Dec 26 10:11:14 2015 library versions: OpenSSL 0.9.8q 2 Dec 2010,
LZO 2.04
Quoted 5 lines
Sat Dec 26 10:11:16 2015 WARNING: Your certificate has expired!
this is about as old as it gets - thanks a lot. Mogrified into a patch against git master with the SSL_free() moved to the right place attached below, for Steffan to ACK.
ACK, much wanted functionality and code looks good.
-Steffan
------------------------------------------------------------------------------
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Илья Шипицин

2016-01-02 18:14 UTC #12 lore raw

In reply to Steffan Karger

also, does it make sence to perform unit testing on build like

setup server with user/password auth on localhost, connect to is using client, see whether it is ok....

2015-12-26 12:40 GMT+03:00 Steffan Karger <[email protected]...>:

Quoted 32 lines · Gert Doering

Quoted 10 lines · Jan Just Keijser
Quoted 5 lines
I justed wanted to get back to this one one more time: attached is a patch to ssl_openssl.c that works in combination with Steffan's patch to check for expired certificates. This new patch-patch works on my CentOS 6 (openssl 1.0.1e) box :) This patch was done against the v2.3.9 code base and I have no clue how to get it into proper git formatting ;)
Great discovery :-) - and it nicely works for me:
Sat Dec 26 10:11:14 2015 OpenVPN 2.3_git
[git:ssl-expire/0f7319906a9dff58+] amd64-unknown-freebsd7.4 [SSL (OpenSSL)] [LZO] [LZ4] [MH] [IPv6] built on Dec 26 2015
Quoted 1 line
Sat Dec 26 10:11:14 2015 library versions: OpenSSL 0.9.8q 2 Dec 2010,
LZO 2.04
Quoted 5 lines
Sat Dec 26 10:11:16 2015 WARNING: Your certificate has expired!
this is about as old as it gets - thanks a lot. Mogrified into a patch against git master with the SSL_free() moved to the right place attached below, for Steffan to ACK.
ACK, much wanted functionality and code looks good.
-Steffan
------------------------------------------------------------------------------
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Gert Doering

2016-01-02 18:47 UTC #13 lore raw

Hi,

Quoted 4 lines · ???????? ??????????????

also, does it make sence to perform unit testing on build like
setup server with user/password auth on localhost, connect to is using client, see whether it is ok....

We do, but we don't run test setups without certificates (my auth/pass users *also* have to have a certificate - helps against lost passwords, because you also need to steal key+cert)

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Илья Шипицин

2016-01-02 18:53 UTC #14 lore raw

as for my observation, people share password with coworkers, they will share cert in the same way :)

well, password-only is legitimate setup, so I would add test case for it. maybe bit later.
where can I have a look at existing test cases you are talking about?

суббота, 2 января 2016 г. пользователь Gert Doering написал:

Quoted 22 lines

Hi,
Quoted 4 lines · ???????? ??????????????
also, does it make sence to perform unit testing on build like
setup server with user/password auth on localhost, connect to is using client, see whether it is ok....
We do, but we don't run test setups without certificates (my auth/pass users *also* have to have a certificate - helps against lost passwords, because you also need to steal key+cert)
gert
--
USENET is *not* the non-clickable part of WWW!
                                                           //
www.muc.de/~gert/
Gert Doering - Munich, Germany
[email protected]... <javascript:;>
fax: +49-89-35655025
[email protected]... <javascript:;>

Gert Doering

2015-12-26 10:41 UTC #15 lore raw

[Openvpn-devel] [PATCH applied] Re: Make certificate expiry warning patch (091edd8e299686) work on OpenSSL 1.0.1 and earlier.

In reply to Gert Doering

Patch has been applied to the master and release/2.3 branch.

commit 0e591a2fce325e2b91d429ea18aa6ed383330383 (master) commit ca6045756e90a6efbad0bc7c2ad84443926ae9d4 (release/2.3)

Author: Jan Just Keijser
Date:   Sat Dec 26 10:15:04 2015 +0100

     Make certificate expiry warning patch (091edd8e299686) work on OpenSSL 1.0.1 and earlier.

     Signed-off-by: Gert Doering <[email protected]...>
     Acked-by: Steffan Karger <[email protected]...>
     Message-Id: <[email protected]...>
     URL: http://article.gmane.org/gmane.network.openvpn.devel/10881

--
kind regards,

Gert Doering

2015-12-16 08:24 UTC #16 lore raw

In reply to Jan Just Keijser

Hi,

Quoted 8 lines · Jan Just Keijser

is loaded, but - as Steffan pointed out - this would mean that multiple places need a function call to check this:
- when loading an x509 file
- when loading a pkcs12 file
- when loading an inline blob
- when loading something from pkcs11
- when loading something via cryptostore
- when loading something using the management interface

... which means "truly a lot of places", and we'll end up maintaining that code for quite a long time...

[..]

Quoted 4 lines

I'm inclined to alter the patch to check it at all items listed above - what do you guys think?
Having to wait for openssl 1.0.2 (which even my fedora 22 box does not yet have) seems a bit like "so close, yet so far ..."

OTOH, 0.9.8 and 1.0.0 will be discontinued end of this year, so we should see vendor upgrades.

Or, as Steffan remarked, just use PolarSSL - which is its own can of worms, but at least, this functionality is there nicely. If you have 1.3, that is, so in the 2.3 release train, it won't work before 2.3.10 (argh on all crypto libraries...)

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

David Sommerseth

2015-12-16 13:30 UTC #17 lore raw

Quoted 3 lines · Gert Doering

OTOH, 0.9.8 and 1.0.0 will be discontinued end of this year, so we should see vendor upgrades.

Enterprise distributions will not rebase OpenSSL on their supported distroes. RHEL5 will continue to ship the openssl-0.9.8 base. But it will be, as it always has, maintained by Red Hat. So security and critical bugs will be provided. I expect SuSE does something similar to their enterprise release as well.

FTR ... RHEL 5 is fully supported until end of March 2017. Customers paying for an extended life cycle support add-on (ELS) will get critical-impact security fixes. For more information:
<https://access.redhat.com/support/policy/updates/errata>

Even though I know it would be good to get rid of the support for these old OpenSSL versions ... we can't just kick them out like that. Not yet. James have asked us to keep RHEL 5 support as long as it is supported by Red Hat. I think it is fine for us to aim for March 2017.
Then it will be RHEL 6 which is our next target (openssl-1.0.1 base).

With that said. I do not not think it is necessarily worthwhile to insist on 'git master' being supported on RHEL 5, especially if it begins to be painful to support RHEL 5 on our bleeding edge code base. In that perspective I would not mind if we consider the coming OpenVPN 2.4 to be the newest OpenVPN release we support on RHEL 5. I would prefer not going any older than 2.4 though.

Signature · 3 lines

kind regards,

David Sommerseth