Closed GoogleCodeExporter closed 9 years ago
Can you provide a patch?
Original comment by g.rodola
on 31 May 2013 at 12:49
Hi,
I can. It's a one-liner. Using the use_certificate_chain_file() instead of
use_certificate_file() allows placing intermediate certificates into the same
PEM encoded file after the subject certificate and is actually preferred
according to https://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html
--- handlers.py.orig 2014-02-14 03:27:46.000000000 +0400
+++ handlers.py 2014-02-14 03:39:52.000000000 +0400
@@ -3239,7 +3239,7 @@
cls.ssl_context.set_options(SSL.OP_NO_SSLv2)
else:
warnings.warn("SSLv2 protocol is insecure", RuntimeWarning)
- cls.ssl_context.use_certificate_file(cls.certfile)
+ cls.ssl_context.use_certificate_chain_file(cls.certfile)
if not cls.keyfile:
cls.keyfile = cls.certfile
cls.ssl_context.use_privatekey_file(cls.keyfile)
Original comment by dop251
on 14 Feb 2014 at 12:05
I'm not a SSL expert so I need to ask: is that backward compatible with current
functionality? Have you tried running tests after applying the patch?
Original comment by g.rodola
on 14 Feb 2014 at 12:08
I'm not an expert either, but the API docs is quite clear: as long as the
certificate file is in PEM format it should not create any regression. And
because there is no way of specifying the certificate file format in pyftpdlib
anyway it works out pretty well.
I have run the tests, all passed.
Original comment by dop251
on 14 Feb 2014 at 8:47
Fixed in r1252.
Original comment by g.rodola
on 11 Apr 2014 at 5:12
Nice one, many thanks.
BTW, why did the credit go Brian? :)
Original comment by dop251
on 11 Apr 2014 at 5:20
Whops! You're right, sorry. What's your name? =)
Original comment by g.rodola
on 11 Apr 2014 at 5:22
N: Dmitry Panov
C: UK
E: dop251@gmail.com
Original comment by dop251
on 11 Apr 2014 at 5:25
Done.
Original comment by g.rodola
on 11 Apr 2014 at 5:27
Original comment by g.rodola
on 3 Jun 2014 at 9:46
Original issue reported on code.google.com by
brianto...@gmail.com
on 30 May 2013 at 10:04