Opened 8 years ago
Closed 8 years ago
#6274 enhancement closed wontfix (wontfix)
CertificateOptions should support privateKeyFileName & certificateFileName
Reported by: | Hynek Schlawack | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | core | Keywords: | |
Cc: | Hynek Schlawack | Branch: | |
Author: |
Description
I’m not sure if this is a long shot, but unfortunately I live in the wrong time zone and nobody on IRC reacted, so I put it into an ticket (trace/google searches didn’t unearth anything on the tracker):
Due to #2061, I learned about CertificateOptions
. Now, it is my understanding, that our SSL code is supposed to be abstracted away from PyOpenSSL and that CertificateOptions
is supposed to supersede DefaultOpenSSLContextFactory
.
Now, there are IMHO two problems standing in the way:
- It badly needs documentation, “Using SSL in Twisted” barely mentions it and I had to look into Twisted’s code to figure out how to use it. cf. #6273
- It’s clunky to use.
They equivalent of
DefaultOpenSSLContextFactory( privateKeyFileName=sslKey, certificateFileName=sslCert, )
is
CertificateOptions( privateKey=PrivateCertificate.loadPEM( FilePath(sslKey).getContent() + FilePath(sslCert).getContent()).privateKey.original, certificate=Certificate.loadPEM( FilePath(sslCert).getContent()).original )
I’m somehow afraid I’m totally missing some point here, but I’m going forward and propose the addition of privateKeyFileName
& certificateFileName
that behave like the ones of DefaultOpenSSLContextFactory
and are mutually exclusive to privateKey
and certificate
.
Change History (2)
comment:1 Changed 8 years ago by
Cc: | Hynek Schlawack added |
---|
comment:2 Changed 8 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Thanks for pointing out this issue, hynek. I think it would be a good idea to resolve #6273 first and then reconsider whether some part of
CertificateOptions
needs to be made more convenient. Without proper usage documentation, I think you might have missed an easier wayCertificateOptions
can be used. It may be that even with the most convenient usage documented, it's still clunkier than we want. If that turns out to be the case, I encourage you to re-open this ticket. Thanks again!