CertificateOptions should support privateKeyFileName & certificateFileName

[Hynek Schlawack]

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:

1. 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
2. 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.

[Jean-Paul Calderone]

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 way CertificateOptions 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!