[JENKINS-70000] Fix HTTPS user cert auth for (temporary) private CA #120
Conversation
…redentials with trusted certs (private CA) * try to loadTrustMaterial(), * warn if keystore pass is trivial so PKCS12 does not load everything, * support ignoreSslErrors flag, * and log progress through auth()
…(lift from credentials-plugin)
|
Conjured up some unit tests to make sure new functionality gets called. Historically, I had local-branch tests for this complete with parsing PEM data of our local SUT certs and constructing a credential on the fly, making a separate-JVM agent, and whatnot - too much (and partially too intimate) to publish. Then my focus shifted to jenkinsci/credentials-plugin#391 as a related problem (JENKINS-70101), and much of the test suite was cleaned up and published there. And finally a copy drifted back here to publishable branch, along with "credentials-plugin"'s approach of pre-populated P12 keystore files among test resources. After that other issue (JENKINS-70101) is addressed, the tests here may get expanded with a remote-agent case. Also note that these tests DO NOT make actual HTTPS queries offsite, less so to some usercert-protected resource. That would be a very different effort to even set up such an instance (especially if self-contained in the test suite). The tests added now focus on plugin handling of the credential to extract Trusted and Key "Materials" while preparing the request, and not crashing overall. |
|
...and? Can it be merged then? :-D |
|
Hi, Is there any hope to have this merged & released? Or is there a workaround to get custom certificates used by the httpRequest plugin? Thanks, |
jimklimov
force-pushed
the
fix-cert-auth
branch
2 times, most recently
from
2937c95
to
cc65bcf
Compare
|
Bumped to reconcile README changes in master branch. |
|
Yay! Thanks :) Now we can worry about one less custom-forked plugin :) |
https://issues.jenkins.io/browse/JENKINS-70000
Our tests are done against SUTs which provide their newly made CA which issues both web-server and user (login) certificates. As such, we can not use JDK or Jenkins persistent cert db files to trust those.
Jenkins Certificate credentials can actually store certificates (not just user keys as commonly used), but http-request-plugin can not build the trust chain for such almost-self-signed certs.
It took me several days to track down what went wrong in the web of KeyStore and Cert processing implementations involved, but ultimately I've reproduced and fixed the issue. Lack of trust handling in the plugin required relatively little changes (after all most time spent was in the and docs and other components' sources). A much larger effort was to make at least an internal test case which uploads the certs and keys involved, so I could step though code as I iterated this change and collected roadblocks.
When generating the P12 keystore to upload, one can add private CA certificates as Trusted - it does not suffice to just have a chain (attached to private key) ending with that cert. One notable caveat here is that keystore password must be nontrivial (not null or empty string; however a single space is good enough), otherwise PKCS12KeyStore ignores certs in keystore.
While I have locally made the test cases for this, they do not make much sense for the internet publication (involving private CA for temporary servers on LAN). I can try to adapt that code for publication, if someone can walk me through spawning an HTTPS server in Java, with access protected by user certs (something for the test to query with and without certs for a meaningful activity). FWIW, creation of in-memory PKCS12 keystore from PEM file(s) with keys and certificates seems easy with code examples like https://stackoverflow.com/a/48173910/4715872 and https://stackoverflow.com/a/25650305/4715872 - just
keystore.store()not into a file, but into a byte array stream which then is fed to UploadedKeyStoreSource. Otherwise someone turning https://github.com/ctron/pem-keystore into a Jenkins plugin (or extending the standard one to accept more keystore file types) sounds like an option.