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

(WIP) Support for HTTPS #22

Merged
merged 1 commit into from
Apr 7, 2020
Merged

(WIP) Support for HTTPS #22

merged 1 commit into from
Apr 7, 2020

Conversation

zharinov
Copy link
Contributor

@zharinov zharinov commented Dec 12, 2019

Basically, it's not that hard to pass couple options to enable SSL (and HTTP/2 as well).
However, after some initial research, I have some questions to elaborate on:

  1. Are :key-managers and :trust-managers options needed as well, or it would be okay for users to pass it explicitly to SSLContext?
  2. Undertow docs mention Wildfly OpenSSL provider as the better performing alternative to the default one. But, (a) it means one more additional dependency and (b) can potentially cause problems with native GraalVM-based builds (Support GraalVM as target #7).
  3. Wouldn't be this interface too low-level? For users who aren't so familiar with Java cryptography APIs, list of possible misconfigurations look pretty scary. For keys obtained via "Let's encrypt" or environment variables, potential user-friendly pem-string->ssl-context can be implemented using bouncycastle/bcpkix-jdk15on, but again: one more dependency. Plus, some additional responsibility is required for implementing it right way (this repo can be useful).

@ikitommi
Copy link
Member

ikitommi commented Apr 7, 2020

Looks good, thanks!

@ikitommi ikitommi merged commit 022a44e into metosin:master Apr 7, 2020
@zharinov
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants