[JIRA] (JENKINS-49761) SSL Error in Github API connection
Title: Message Title Joseph Crotty commented on JENKINS-49761 Re: SSL Error in Github API connection Exact same issue has been happing since Feb. 22, 2018 on our Jenkins install for all Github Pull Requests. We tried the solution here but no luck. This has our test builds totally dead in the water. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows from project build that uses the HTTP Request setup I illustrated above:{noformat}...HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]...{noformat}If you need a URL to test/debug against that currently has an expired Cert you can use this one but be warned it'll probably stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired: {noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat} Jenkins console output snippet follows from project build that uses the HTTP Request setup I illustrated above: {noformat}...HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]...{noformat}If you need a URL to test against that currently has an expired Cert you can use this one but be warned it'll stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows from project build that uses the HTTP Request setup I illustrated above:{noformat}...HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]...{noformat}If you need a URL to test /debug against that currently has an expired Cert you can use this one but be warned it'll stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows from project build that uses the HTTP Request setup I illustrated above:{noformat} ... HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399] ... {noformat}If you need a URL to test against that currently has an expired Cert you can use this one but be warned it'll stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows from project build that uses the HTTP Request setup I illustrated above: {noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}If you need a URL to test against that currently has an expired Cert you can use this one but be warned it'll stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat} If you need a URL to test against that currently has an expired Cert you can use this one but be warned it'll stop resolving in the next couple of months:curl -i "https://metrics.datapipe.senderscore.net/"
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a an improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GETHere is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat}Jenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE}HTTP mode: GETJenkins console output snipped snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/${RPM_FILE\}HTTP mode: GET Here is curl example showing the cert in question has expired:{noformat}$ curl -i "https://internal.rpm.datapipe.senderscore.net/health"curl: (60) SSL certificate problem: certificate has expiredMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option.If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL).If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.{noformat} Jenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/$ \ {RPM_FILE\}HTTP mode: GETJenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/ \ ${RPM_FILE}HTTP mode: GETJenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty updated an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Change By:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS.URL: https://internal.rpm.datapipe.senderscore.net/publishfile/ \ $ \ {RPM_FILE \ }HTTP mode: GETJenkins console output snippet follows{noformat}HttpMode: GETURL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmSending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpmResponse Code: HTTP/1.1 200 OKSuccess code from [100‥399]{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-41934) HTTPS/TLS Cert check bypassed
Title: Message Title
Joseph Crotty created an issue
Jenkins / JENKINS-41934
HTTPS/TLS Cert check bypassed
Issue Type:
Bug
Assignee:
Janario Oliveira
Components:
http-request-plugin
Created:
2017/Feb/10 4:39 PM
Environment:
Jenkins ver. 2.32.2 LTS (i.e., docker 2.32.2:latest) HTTP Request Plugin 1.8.13 All plugins are current
Priority:
Major
Reporter:
Joseph Crotty
I am using http-request-plugin to call an API end point using HTTPS. The cert associated with the domain has expired so I would expect the API call to fail, but low and behold the call succeeds and even claims a HTTP 200 header response. I don't know whats happening under the covers so not sure if this is a bug or a improvement/feature, but I am 100% certain it's not using HTTPS or some flag is being used internally to circumvent TLS. URL: https://internal.rpm.datapipe.senderscore.net/publishfile/$ {RPM_FILE} HTTP mode: GET Jenkins console output snipped follows
HttpMode: GET
URL: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpm
Sending request to url: https://internal.rpm.datapipe.senderscore.net/publishfile/tusko_message_stream-3.0.0-SNAPSHOT20170210153816.noarch.rpm
Response Code: HTTP/1.1 200 OK
Success code from [100‥399]
