Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgraded from v1.1.0 to v1.2.0 produces Hostname/IP does not match certificate's altnames: Host: smee.io. is not in the cert's altnames #156

Open
Ginxo opened this issue Sep 1, 2020 · 5 comments · Fixed by distributed-system-analysis/smee-client#1

Comments

@Ginxo
Copy link

Ginxo commented Sep 1, 2020

Hi,

first of all thanks for the support. We are using smee.io service/client to communicate github events with our internal Jenkins instance (nothing new here). We upgraded smee-client npm library from v1.1.0 to v1.2.2 and then this error is produced https://issues.redhat.com/browse/BXMSPROD-983

Connected https://smee.io/
Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: smee.io. is not in the cert's altnames: xxxxx
....
  code: 'ERR_TLS_CERT_ALTNAME_INVALID',
  response: undefined
}

We decided to force our machine to use v1.1.0 [1] and now it's working. I've been analyzing your changes from v1.1.0 to v1.2.2 and I can see:

  • You added typescript and adapted client/index.js to client/index.ts (NOT AFFECTING)
  • You format target url using url.format (NOT AFFECTING)
  • You removed server code from there (SHOULD NOT AFFECT)
  • You upgraded these libraries (most probably by dependantbot):
    • commander@^2.12.2 to ^2.19.0 (NOT AFFECTING, treating command line args)
    • eventsource@^1.0.5 to ^1.0.7 (it shouldn't affect to us, since it's just treating HTTP events)
    • morgan@^1.9.0 to ^1.9.1 (NOT AFFECTING, logger)
    • validator@10.4.0 to ^10.11.0 (NOT AFFECTING, string validators and sanitizers)
    • superagent@^3.8.3 to ^5.0.2 (this is most probably the one which is introducing the error since is the library they use for pushing events).

It's true we can setup our certificates to include smee.io stuff but I wanted to let you know, in case you are not aware, you introduced a new integration step to perform in case you want to use smee stuff, we liked smee as it was 💘

[1] kiegroup/kie-ci#807
related to https://issues.redhat.com/browse/BXMSPROD-983

@brtduvally
Copy link

I'm seeing the same issue on RHEL 7. Only way to make 1.2.2 work was to use NODE_TLS_REJECT_UNAUTHORIZED. Once I downgraded to 1.1.0 it started working correctly.

kahowell added a commit to kahowell/smee-client that referenced this issue Mar 4, 2021
With some hosts behind shared TLS (using SNI), keeping the Host header
was causing the target host to be misidentified.

I also observed issues related to TLS verification (as seen in probot#156).

Fixes probot#156
@winklerm
Copy link

winklerm commented Mar 18, 2021

Just wanted to mention that the host header is making trouble with smee.io redirecting to a Jenkins master running in OpenShift (the HTTP response to the redirect is 503). Fixing this issue would help us a lot, thank you!

@Ginxo
Copy link
Author

Ginxo commented Mar 19, 2021

@gr2m any idea/update on this?
I would be glad to contribute but I would need a bit of guidance here, can you please provide it?

Thanks,
Kike

winklerm added a commit to winklerm/kie-ci that referenced this issue Mar 25, 2021
Add workaround for [1] by building smee-client from a fork with the fix
[2].

[1] probot/smee-client#156
[2] probot/smee-client#162
mbiarnes pushed a commit to kiegroup/kie-ci that referenced this issue Mar 25, 2021
Add workaround for [1] by building smee-client from a fork with the fix
[2].

[1] probot/smee-client#156
[2] probot/smee-client#162
@gr2m
Copy link
Contributor

gr2m commented Mar 31, 2021

I'm afraid I cannot give a lot of guidance, I never worked on smee myself, I'm afraid to introduce regressions if we do any changes. The PR at #162 does not have any tests, and I don't know enough about smee to be confident that the change won't break things for existing users

@derekjobst
Copy link

Also seeing this issue. Suggested user revert to 1.1.0 or set the NODE_TLS_REJECT_UNAUTHORIZED flag. Looking forward to the fix in #162 :)

kahowell added a commit to kahowell/smee-client that referenced this issue Oct 18, 2022
With some hosts behind shared TLS (using SNI), keeping the Host header
was causing the target host to be misidentified.

I also observed issues related to TLS verification (as seen in probot#156).

Fixes probot#156
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants