search

mohamicorp / stash-jenkins-postreceive-webhook

Webhook used to notify Jenkins when commits are made to Stash
Other
138 stars 98 forks source link

SSL Certificate Checks #72

Open TJM opened 10 years ago

TJM commented 10 years ago

Even with the checkbox checked to "Skip SSL Certificate Validation" I get the following error: Error: hostname in certificate didn't match: <sf-itjenkins-01> != <test site>

I am using the "default" SSL capability built into Jenkins, which apparently creates an SSL cert for "<test site>" (ugh)... I will look into that, but in the mean time, shouldn't "Skip SSL Certificate Validation" work?

mikesir87 commented 10 years ago

It should, but it appears it doesn't. It is currently modifying the TrustManager to allow all certificates trust-wise, but doesn't swap out the hostname verifier. That'll be an easy fix, but will try to batch in some of the other bug fixes in before a release comes out. So, may be a few days to a week. That alright?

wrprice commented 10 years ago

Please consider swapping out the hostname verification step optional. Better yet, allow the user to upload the specific certificate to be trusted rather than just trusting any/everything.

mikesir87 commented 10 years ago

Thanks William for your input. Managing and uploaded certificate (potentially for each repository) would probably be considered overkill for this plugin. For the amount of effort required and for the amount of security gained, I'm not sure it's worth the time. After all, the plugin is only making a GET request to a URL, with no secure data transmitted, and ignoring the response. However, feel free to contribute code if you think otherwise.

As far as making the hostname verification optional, I think it's still optional as they are specifying they want to allow ALL SSL certificates. I'll thinking that adding a link of "why is this a bad idea?" to the setting may help, pointing to documentation on the right way to install a certificate.

Thoughts?

TJM commented 10 years ago

As far as "trusting" specific CA certs, I think that would be a Jenkins wide setting, and should, ideally be handled by adding the certs as trustedCertificateEntry(s) to the keystore used by Jenkins. It might make sense to setup a "global" preference (?) for this module to override the keystore, but that seems a bit overkill.

Re: a few days.. I just have my Jenkins polling every 5 minutes for now

TJM commented 10 years ago

Realistically, I find it awful that Jenkins generates a new SSL cert each time it starts. If it would just generate an SSL cert the first time and keep using the same cert, it would be easy to fix this. I realize that I can create an SSL cert for Jenkins and put in all the options to make it work, or front-end jenkins with a proper web server, but I don't understand in what context a new SSL cert every restart makes any sense.

Tommy

jbnance commented 7 years ago

The "Skip SSL Certificate Validation" checkbox still doesn't work fully. In my case the BitBucket server accesses the Jenkins server using a different hostname than the certificate was generated, which yields:

Error: Certificate for <jenkins.lab.centric.com> doesn't match common name of the certificate subject: sl2aospljen0001.ipa.lab.gen.zone

Is this expected to be fixed in the current release (3.0.1)?

hendrikhalkow commented 7 years ago

The SSL validation skipping means that it accepts unknown CAs, mainly self-signed authorities. Using a wrong host name in the certificate is just wrong, so what you ask for will (hopefully) bot be implemented. Please fix your certificate instead.

jbnance commented 7 years ago

You're splitting hairs. If you're going to ignore the CA you have already thrown validation out the window. So whether the CN matches the host name or not doesn't mean anything. A certificate is either valid or not. There are no layers of validity.

My use case is perfectly legit - the SSL certificate matches the internal name that is used by every other client to access Jenkins. BitBucket is segregated from that network so it uses a different host/IP to access the service (a NAT through a firewall). For them to match I would have to either setup a DNS view or a proxy with its own SSL certificate - work that makes no sense when the certificate isn't being validated anyway.

As was said above (edit: corrected reference):

...the plugin is only making a GET request to a URL, with no secure data transmitted, and ignoring the response

It's perfectly reasonable to blindly trust the connection.