Visitar URL original
SslContextFactory may select a wildcard certificate during SNI selection when a more specific SSL certificate is present · Issue #6034 · jetty/jetty.project · GitHub
Skip to content

SslContextFactory may select a wildcard certificate during SNI selection when a more specific SSL certificate is present #6034

Closed

Description

@BruceMacD

Jetty version
Observed in jetty-9.4.35.v20201120 but the code is the same in the jetty-9.4.x branch and the jetty-10.0.x branch so it should have the same behavior.

Java version
Oracle JDK 8u281.

OS type/version
Mac OS 10.14 (this should be OS agnostic)

Description
Scenario
Hosting an application in Jetty with two certificates:

  • Certificate 1 with alias *.example.com
  • Certificate 2 with alias sub.example.com

Expected behavior
A request to sub.example.com selects certificate 2 (sub.example.com).

Actual behavior
A request to sub.example.com may select certificate 1 (*.example.com).

Details
This happens because SslContextFactory.sniSelect() returns the first certificate that matches the SNI host. If the wildcard cert happens to be stored first in the collection it will be returned with this behavior. I notice that X509.matches() checks wilds as well as hosts for a match, if there was a specific host match check in the SslContext factory before doing the more general match check then this behavior would be fixed.

This may be expected behavior, but it would be pretty simple to correct so I thought it was worth mentioning.

Activity

  1. sbordet commented on Mar 4, 2021

    @sbordet
    Contributor

    @BruceMacD as a workaround, you can always set your own SNISelector on SslContextFactory to implement a more precise logic.

    I agree that we should try to match the precise domain first, then wildcard domains.

  2. added a commit that references this issue on Mar 4, 2021
    7aa69c0
  3. sbordet commented on Mar 4, 2021

    @sbordet
    Contributor

    @BruceMacD can you try #6036?

  4. BruceMacD commented on Mar 4, 2021

    @BruceMacD
    ContributorAuthor

    @sbordet
    That change works perfectly in my case. Thanks.

  5. added 2 commits that reference this issue on Mar 8, 2021
    203fff7
    132f4b9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions