Offer a way to start the RealJenkinsRule instance with https only

[Vlatombe]

This allows to start RealJenkinsRule instances listening on https instead of http. A self-signed certificate matching the given host name (or localhost if unspecified) is automatically generated (using bouncycastle)

Various methods are offered to allow callers to access the RealJenkinsRule clients to access the instance without disabling security.

Also added utilities related to key store and self-signed certificate management.

Testing done

Submitter checklist

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [ ] Link to relevant issues in GitHub or Jira
• [ ] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jtnord]

A self-signed certificate matching the given host name (or localhost if unspecified) is automatically generated (using bouncycastle)

is there a reason you need to access the RealJenkinsRule via the host name? if testing multiple RealJenkinsRules side by side and you want a nice jenkins-1 using some form of nip.io then would it not behove us to add a static SSL cert generated once and checked in (and skip generating on demand) that has subject altanmes for localhost, ::1, 127.0.0.1, *.nip.io, *.localhost.me ..,.. (insert any other providers here).

[Vlatombe]

is there a reason you need to access the RealJenkinsRule via the host name?

The point here is to test close to real life scenarios:

• a reverse proxy set up with https (public-jenkins.acme.com)
• a RealJenkinsRule instance set up with https (internal-jenkins.acme.com)

Each one using different https certificates (so external users must trust CA for the reverse proxy, then reverse proxy must trust CA from RJR instance).

Checking in a static certificate would do if I had only one RealJenkinsRule instance, but I want guarantee that trust stores are setup appropriately so for test purpose, I think it is better to have a single certificate generated for each instance.

[jtnord]

• a reverse proxy set up with https (public-jenkins.acme.com)
• a RealJenkinsRule instance set up with https (internal-jenkins.acme.com)

This seems like a very specific setup useful for a very narrow set of plugins (one or two?). Check-in the 3 certs in the specific project(s) and expose a method to use a specific cert (or keystore) for a specific RealJenkinsRule instance. Then the default checked in cert here work all the other plugins that just want a valid TLS endpoint.

or employ shading in this project so that the library does not leak and will not affect plugins using the bouncycastle-api either regularly or in the PCT.