-
Notifications
You must be signed in to change notification settings - Fork 50
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
SNI is not Supported on the Server #70
Comments
@vietj I am guessing the issue here could be related how core is used to start the server. |
@pmlopes I think this is an issue of gRPC Netty server. SNI requires a specific Netty Handler to operate. |
note that if we reimplement a Vert.x transport for gRPC this would work |
I created this issue because I believe this is a desirable feature to have in v4 #83 |
See grpc/grpc-java#7397 (comment) where I was advised that SNI support with grpc-java is recommended to be achieved by manipulating the key store and relying on default handling for SNI in Java |
if we were to reimplement gRPC transport with Vert.x we would benefit from
that.
…On Thu, Mar 25, 2021 at 2:59 PM Liam Williams ***@***.***> wrote:
See grpc/grpc-java#7397 (comment)
<grpc/grpc-java#7397 (comment)>
where I was advised that SNI support with grpc-java is recommended to be
achieved by manipulating the key store and relying on default handling for
SNI in Java
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXDCXDW7WIL2DHE5OCSBLTFM6VLANCNFSM4NS5GZ3Q>
.
|
With SNI enabled, the server can handle multiple certificates. During the TLS handshake, the client indicates the service name allowing the service to looks for the correct certificate and completes the handshake. The JKS and PKCS12 format allow the key stores to contain multiple certificates. However, the PEM format does not allow that. For this reason, the configuration of the PEM certificate and key are now accepting lists of paths. The previous (singular) form are deprecated but still supported. SNI must be enabled explicitly as the server cannot verify if the key stores contain multiple certificates (JKS / PKCS12). This commit does not enable SNI on gRPC, as the gRPC server does not handle it. See vert-x3/vertx-grpc#70 for details. Fix quarkusio#16851
With SNI enabled, the server can handle multiple certificates. During the TLS handshake, the client indicates the service name allowing the service to looks for the correct certificate and completes the handshake. The JKS and PKCS12 format allow the key stores to contain multiple certificates. However, the PEM format does not allow that. For this reason, the configuration of the PEM certificate and key are now accepting lists of paths. The previous (singular) form are deprecated but still supported. SNI must be enabled explicitly as the server cannot verify if the key stores contain multiple certificates (JKS / PKCS12). This commit does not enable SNI on gRPC, as the gRPC server does not handle it. See vert-x3/vertx-grpc#70 for details. Fix quarkusio#16851
With SNI enabled, the server can handle multiple certificates. During the TLS handshake, the client indicates the service name allowing the service to looks for the correct certificate and completes the handshake. The JKS and PKCS12 format allow the key stores to contain multiple certificates. However, the PEM format does not allow that. For this reason, the configuration of the PEM certificate and key are now accepting lists of paths. The previous (singular) form are deprecated but still supported. SNI must be enabled explicitly as the server cannot verify if the key stores contain multiple certificates (JKS / PKCS12). This commit does not enable SNI on gRPC, as the gRPC server does not handle it. See vert-x3/vertx-grpc#70 for details. Fix quarkusio#16851
I am using the latest 4.0.0-SNAPSHOT of the Vert.x stack. I tested this with the Java server app running on macOS 10.15.14, ubuntu 20.04, Windows 10 on a AdoptOpenJDK 11.0.7 JVM. I am using openssl test client like so :
openssl s_client -showcerts -servername grpc.example.com -connect grpc.example.com:443
I am setting the SSL options with the
setPfxKeyCertOptions
andsetSni(true)
. The PFX/P12/PKCS 12 key store contains key/cert entries for all the hostnames the server is serving for, including "localhost", and for the sake of this example, "grpc.example.com". If I start a normal Vert.x HTTP/2 server, it responds to the test openssl command correctly, whereas the gRPC server does not.The text was updated successfully, but these errors were encountered: