Add private key password option to ssl adapters

[jatalahd]

• It is now possible to use password protected private keys in both builtin and openssl ssl-adapters
• Added also positive and negative unit test cases
• With reference to Password support for SSL certificates cherrypy#1583

❓ What kind of change does this PR introduce?

• 🐞 bug fix
• 🐣 feature
• 📋 docs update
• 📋 tests/coverage improvement
• 📋 refactoring
• 💥 other

📋 What is the related issue number (starting with #)

cherrypy/cherrypy#1583

❓ What is the current behavior? (You can also link to an open issue here)
With the current functionality it is only possible to use ssl adapters with private keys without password protection

❓ What is the new behavior (if this is a feature change)?
With this change, there is a new option to give the ssl adapter a "private_key_password" argument, which can be in either string or bytestring format.

📋 Other information:
Added also unit tests to test the new functionality

📋 Contribution checklist:

• I wrote descriptive pull request text above
• I think the code is well written
• I wrote good commit messages
• I have squashed related commits together after
  the changes have been approved
• Unit tests for the changes exist
• Integration tests for the changes exist (if applicable)
• I used the same coding conventions as the rest of the project
• The new code doesn't generate linter offenses
• Documentation reflects the changes
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences

---

This change is 

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.55%. Comparing base (4a8dc43) to head (5072e24).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #752      +/-   ##
==========================================
+ Coverage   79.30%   79.55%   +0.25%     
==========================================
  Files          29       29              
  Lines        4203     4261      +58     
  Branches      539      542       +3     
==========================================
+ Hits         3333     3390      +57     
+ Misses        728      727       -1     
- Partials      142      144       +2     

[jatalahd]

Fixed linter issues with second commit, but now it seems that I need to do the git squash... Anyway, it would be important for us to get this improvement into some upcoming cheroot release, which we can then reference in our pipfile so that we can take these changes into use.

[jatalahd]

@webknjaz ; I understand that you are busy, but I am pinging you because you seem to be the only administrator actively working on this repository. I am hoping that we could proceed with this pull request until I forget what have I done. I assume at least the review is required, but maybe some other tasks need to be still done until this can be merged?

[webknjaz]

@jatalahd thanks for the contrib! You don't have to squash commits unconditionally. Only if the commits are non-atomic. If they aren't, it's usually a good idea to combine them to keep Git history clean.

One thing that's definitely missing is a change note. Read https://cheroot.cherrypy.dev/en/latest/contributing/guidelines/#adding-change-notes-with-your-prs and follow the guidelines. Do you best and if it needs editing, I'll tell you.

I can't give you a timeline right now. I'm a bit unhappy about the state of the TLS adapters in general and wanted to redesign them eventually. And so I'm a bit hesitant on what changes would be acceptable in the public API. I'll need to think about it first.

I'll leave a few notes in the diff but that'll be an incomplete review.

[jatalahd]

@webknjaz ; Thanks for reviewing the code. I fixed all problems you mentioned (as well as I could). Added also change note and had to do the git squash to clean up the git history. Due to that, I had to force push and therefore your review comments disappeared from the "files changed" -tab. However I answered all those comments in this conversation-tab. Please let me know if there is something that still needs fixing.

[jatalahd]

With the latest two pushes, I fixed one linter issue and one test fail that was occuring on Ubuntu arm platform. To me the CI pipeline results look fine, the remaining test failures are not due to my commit. I consider this now ready for hopefully final review.

[jatalahd]

@webknjaz ; I am still hoping that this improvement will be included in some upcoming cheroot release. We are currently using a workaround of creating a local wheel of cheroot with this change included and that cannot be a sustainable solution in long term.

[webknjaz]

@jatalahd I've added a few comments + you need to rebase to pick up the recent main. But overall seems good.

[webknjaz]

@jatalahd looks like this is amost ready. Only cosmetic changes left mostly.

[jatalahd]

@webknjaz Provided improvements as you suggested. I hope this is OK now.

[webknjaz]

@jatalahd it's probably a good idea to paste a full link to the CherryPy issue in the commit message. Only using the number makes GH link issues in this repository instead.

[jatalahd]

@webknjaz Yet another improved push provided.

[webknjaz]

@jatalahd looks like the docstring adjustments is the last thing left before I can merge.

[jatalahd]

@webknjaz Docstrings changed as suggested in latest push.

[webknjaz]

Perfect, thanks!

[webknjaz]

@jatalahd this test turned out to be flaky. See https://github.com/cherrypy/cheroot/actions/runs/19020536310/job/54314981390#step:15:272 where the error string was "[('DECODER routines', '', 'unsupported'), ('asn1 encoding routines', '', 'too long'), ('asn1 encoding routines', '', 'bad object header'), ('asn1 encoding routines', '', 'nested asn1 error'), ('PKCS12 routines', '', 'decode error'), ('SSL routines', '', 'PEM lib')]" which your regex doesn't match.

Could you send a follow-up PR fixing cheroot/test/test_ssl.py::test_openssl_adapter_with_false_key_password[too-long-password] — looks like the error is sometimes happening with passwords that are too long. Perpahs, encode the regex in parametrize() too, making the too-long-password param expect both error variations?

[webknjaz]

@jatalahd I've released this under v11.1.0:

• https://github.com/cherrypy/cheroot/actions/runs/19020536310
• v11.1.0 #789
• https://github.com/cherrypy/cheroot/releases/tag/v11.1.0
• https://pypi.org/project/cheroot/11.1.0/

---

Though, one test got flaky and needs a follow-up: https://github.com/cherrypy/cheroot/pull/752/files#r2485127496.
Could you handle that, please?

---

Now, this allows sending a PR in the CherryPy repo per cherrypy/cherrypy#1583 (comment).