Add support for exposing server certificate

[Nicoretti]

Dear pytest-localserver maintainers,

First off, I want to send a big 👍 your way. Thanks for providing and maintaining this plugin!

While I was using it in the context of HTTPS, I stumbled upon a few minor issues.
I tried addressing all of these in this PR.

I hope you find the updates useful. If there's anything that needs tweaking or if you'd like me to make any changes, please don't hesitate to let me know.

best

Nico

[diazona]

Thanks for sending a contribution Nico! I'll review this properly later (over the weekend, or tonight if I have time), but for starters, I wonder if you could explain the use cases that led you to propose these changes? (This will probably be good info to edit into the commit messages at some point, but for now we can discuss it in comments.)

[Nicoretti]

Hi @diazona,

No worries take your time. My use cases are quite similar to the ones I've covered in the unit tests of this PR.

When dealing with SSL/TLS, there are three interesting variations, especially concerning server certificate validation when it's not signed by an official Certificate Authority (CA).

1. Verify and abort the connection if validation fails.
2. Proceed without verification (implicitly trust the certificate).
3. Add the certificate to a list of trusted certificates.

Testing scenario 3. requires access to the server's certificate. The httpsserver fixture, with its self-signed certificate, is ideal for this purpose. However, to accurately test this scenario, the server certificate must be made accessible to the client, which was not previously implemented.

While I was on it, I encountered and addressed a few other issues:

• The parameters for sslcontext were passed in an incorrect order. This mistake was subtle, as it didn't manifest while the server's key and certificate were combined in a single .pem file.
• I separated the server.pem into individual key and certificate files (key and crt), allowing them to be exposed separately for more granular control.

best
Nico

[Nicoretti]

For more context: My use cases can be found here and the test(s) you can find here.

[Nicoretti]

This PR likely shows the important bits best.

[diazona]

Thanks for your patience. I like the general idea, I just left some suggestions (which I'm happy to discuss if there's anything you don't agree with).

As for commit organization, I would suggest combining the commits that split the certificate/key files and that make the corresponding changes in the code, so you have three commits in all:

• One that fixes the ordering of cert and key
• One that splits the key into a separate file and makes corresponding updates in the code
• One that adds the certificate() method (and url() if we wind up keeping that one)

Optionally you could break out the tests into a fourth commit, but that's not necessary. The goal is basically to make sure that each commit has a clear purpose, and that the code compiles on each commit (to make bisection easier, if we ever need to do that). This is not a requirement, though, so it's your call if you want to go that far.

[Nicoretti]

...
Optionally you could break out the tests into a fourth commit, but that's not necessary. The goal is basically to make sure that each commit has a clear purpose, and that the code compiles on each commit (to make bisection easier, if we ever need to do that). This is not a requirement, though, so it's your call if you want to go that far.

I totally understand the appeal of having clean and "building" commits (I originally come from a Gerrit-based workflow). While GitHub makes this workflow tricky for various reasons (imho), I'm totally with you on this. So, I suggest once you are satisfied with the PR, I'll squash and rebase it into 3-4 commits.

[diazona]

Whoops I forgot to "officially" leave a review when I commented

[Nicoretti]

@diazona quick heads-up: I'll update the commits and the certificate when I have some downtime. However, it might take me a couple of days.

Just so you know, I intend to follow through on this PR. I'm just a bit short on time over the next few days.

[diazona]

No problem at all, we're in no rush here and it's fine if this takes a few days or even longer to wrap up. I'll be around to help get it finished up whenever you're ready!

[Nicoretti]

@diazona just updated the PR let me know if you need me to do further changes.

[diazona]

Looks good now! Thanks again for the changes.

[diazona]

BTW did you have an interest in getting this PR into a release soon? I hadn't planned on making another release until version 1, whenever that happens, but it'll probably be a while until then. If you'd like these changes available on PyPI earlier, I can make a prerelease to include them or even a version 0.9.

[Nicoretti]

@diazona, there's no immediate rush on my end. My goal is to enhance coverage for certain edge cases eventually.

[diazona]

Sounds good, I'll leave it for whenever the next release happens, then. Thanks again!