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

HTTPS client should support SNI #271

Closed
lizan opened this issue Sep 18, 2017 · 13 comments
Closed

HTTPS client should support SNI #271

lizan opened this issue Sep 18, 2017 · 13 comments
Assignees

Comments

@lizan
Copy link
Contributor

lizan commented Sep 18, 2017

The HTTPS client fetching auth public key doesn't support SNI, in some case ESP won't be able to fetch keys. See #262

@qiwzhang
Copy link
Contributor

Does Nginx proxy_pass upstream support SNI? Is this just our "http.cc" code issue or this is the whole Nginx issue?

@bourquep
Copy link

Any idea when this might be implemented? I'm facing the same situation.

@MrBlaise
Copy link

MrBlaise commented May 31, 2018

Without this I cannot use my custom domain on auth0.

My scenario:

  • Using custom domain on Auth0 for my api.
  • Auth0 manages the certificate for that domain using let's encrypt
  • ESP gives an error:
    2018/05/31 12:44:34 [error] 11#11: upstream SSL certificate verify error: (18:self signed certificate)
    2018/05/31 12:44:34 [warn] 11#11: upstream server temporarily disabled
  • But openssl s_client -showcerts -servername auth.redacted.com -connect auth.redacted.com:443 finds the cert properly (the important part is -servername, without that it fails with self-signed error as well)

@Daniel-Houston
Copy link

We are having the exact problem as mentioned by MrBlaise using our custom domain with Okta. We are unable to use that custom domain until it is fixed.

@lei-tang
Copy link
Contributor

lei-tang commented Jun 6, 2018

@bourquep , @MrBlaise , @Daniel-Houston, can you share your configurations and your steps to reproduce the problem?

@MrBlaise
Copy link

MrBlaise commented Jun 6, 2018

Nothing special configuration, I am doing everything that is written in the Kubernetes Engine tutorial (https://cloud.google.com/endpoints/docs/openapi/get-started-kubernetes-engine) and then set up custom domain according to this: https://cloud.google.com/endpoints/docs/openapi/serving-apis-from-domains I also use auth0 so I followed this guide: https://auth0.com/docs/integrations/google-cloud-platform

The error I get is written in my previous answer.

EDIT:
To reproduce the issue you need a custom domain with a let's encrypt certificate that uses SNI, and try to use that with ESP.

swagger: "2.0"
info:
  description: "REDACTED"
  title: "REDACTED"
  version: "1.0.0"
host: "redacted.redacted.com"
x-google-endpoints:
- name: "redacted.redacted.com"
  allowCors: "true"

@MrBlaise
Copy link

MrBlaise commented Jun 7, 2018

Sorry I left most important part

ecurityDefinitions:
  auth0_jwt:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "https://auth.redacted.com"
    x-google-jwks_uri: "https://auth.redacted.com/.well-known/jwks.json"
    x-google-audiences: "https://redacted.api"

The https://auth.redacted.com will fail with self signed error, when trying to authenticate the user.

lei-tang added a commit to lei-tang/esp that referenced this issue Jun 10, 2018
This PR adds the SNI support for https clients.

Problem solved by this PR:
Per the following two github issues, ESP https clients do not support
SNI (Server Name Indication) for https connections.
cloudendpoints#271
cloudendpoints#262
lei-tang added a commit to lei-tang/esp that referenced this issue Jun 10, 2018
This PR adds the SNI support to ESP for https clients.

Problem solved by this PR:
Per the following two github issues, ESP https clients do not support
SNI (Server Name Indication) for https connections.
cloudendpoints#271
cloudendpoints#262
lei-tang added a commit to lei-tang/esp that referenced this issue Jun 10, 2018
This PR adds the SNI support to ESP for https clients.
Problem solved by this PR: before this PR, ESP https clients do not support SNI (Server Name Indication) for https connections. Details in the following two github issues.
- cloudendpoints#271
- cloudendpoints#262
lei-tang added a commit to lei-tang/esp that referenced this issue Jun 10, 2018
This PR adds the SNI (Server Name Indication) support to ESP for https clients.
Problem solved by this PR: before this PR, ESP https clients do not support SNI for https connections. Details in the following two github issues.
- cloudendpoints#271
- cloudendpoints#262
lei-tang added a commit to lei-tang/esp that referenced this issue Jun 10, 2018
This PR adds the SNI (Server Name Indication) support to ESP for https clients.
Problem solved by this PR: before this PR, ESP https clients do not support SNI for https connections. Details in the following two github issues.
- cloudendpoints#271
- cloudendpoints#262
lizan pushed a commit that referenced this issue Jun 11, 2018
This PR adds the SNI (Server Name Indication) support to ESP for https clients.
Problem solved by this PR: before this PR, ESP https clients do not support SNI for https connections. Details in the following two github issues.
- #271
- #262
@lei-tang
Copy link
Contributor

@MrBlaise , thank you for sharing the steps to reproduce the problem!

@lei-tang
Copy link
Contributor

The support of SNI (Server Name Indication) for https clients has been added to ESP by the commit 3fe87fd.

@MrBlaise
Copy link

Great news! Thank you! When will this release?

@lei-tang
Copy link
Contributor

It should be released either this week or next week.

@lizan
Copy link
Contributor Author

lizan commented Jun 15, 2018

ESP 1.20.0 was released and contains the fix. Let me know if this solves your issue.

@MrBlaise
Copy link

It works now 🎉 Thanks!

@lizan lizan closed this as completed Jun 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants