Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#3064 closed bug (Fixed)

Deluge Web TLS not working with certificate chains

Reported by: Jay-C Owned by:
Priority: major Milestone: 1.3.16
Component: Web UI Version: 1.3.15
Keywords: Cc:



I'm going to try to keep this short. I'm trying to add a certificate chain to the deluge web UI, the subject certificate concatenated with a intermediate certificate, as is standard. I've successfully verified the separate files using the openssl verify" utility.

$ openssl verify -verbose -CAfile root.cert.pem -untrusted intermediate.cert.pem deluge.cert.pem
deluge.cert.pem: OK

However, Firefox gives me an SEC_ERROR_UNKNOWN_ISSUER error. To look at what the server sends my I use:

openssl s_client -CAfile root.cert.pem -connect localhost:8112 -showcerts

Indeed, the output shows the server does not send the intermediate certificate. It seems the deluge web server only sends the first certificate, and skips the rest of the chain. As this has worked correctly in the past, I looked at the git history and the culprit seems to be commit c1902e43, which replaces the code for loading the certificate, specifically

certificate = Certificate.loadPEM([/code]
instead of

As far as I can tell this is an incorrect way to read chain files. Look at the example at for guidance.

I would fix this myself but I'm sure you that have greater experience with the code can do it much quicker and efficiently.

Change History (4)

comment:1 Changed 7 months ago by Cas

Hmm ok, trying solve that issue has unintentionally broken server chaining. I'd want to avoid pem module in 1.3-stable as it pushes the minimum Twisted version to 14.0 but may consider it for develop.

Can you test this change in PR:

Last edited 7 months ago by Cas (previous) (diff)

comment:2 Changed 7 months ago by Jay-C

Yes, that fixes it! Now the certificate verifies as expected. I applied the patch directly on the code distributed in your Ubuntu repositories, so it should be good for 1.3-stable.

In the "wishlist" column, it would be nice if the server didn't ignore the certificate's keyUsage field. Mine is set to "critical, digitalSignature", which should forbid plain RSA but nevertheless the server uses plain RSA. (EC)DHE would very much be preferred in this day and age, shouldn't be to hard to generate a bunch of dhparams and include it with the distribution or generate it dynamically. While we're at it, use AES GCM mode rather than CBC mode, but that's just nitpicking.

Last edited 7 months ago by Jay-C (previous) (diff)

comment:3 Changed 7 months ago by Cas

  • Resolution set to Fixed
  • Status changed from new to closed

Thanks, merged: 1.3-stable [65fac156eb7d6], develop [06dfeed7505dc]

I imagine if we use pem module it would take care of those settings? Can certainly look at doing that for develop, if you could create a feature ticket that would be helpful.

comment:4 Changed 7 months ago by Jay-C

Not sure, I think pem only parses the file? So Twisted would still need to enforce it. But you would need to upgrade Twisted to support Diffie-Hellman and newer cipher suits.

Note: See TracTickets for help on using tickets.