Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-18896

make configuring SSL/TLS connectors trivial

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Parked
    • Affects Version/s: 3.15.0
    • Fix Version/s: None
    • Component/s: Transport
    • Labels:
    • Notability:
      n/a

      Description

      SSL is recommended for web applications.

      NXRM allows setting up secure TLS connectors via typical Eclipse Jetty configuration. The steps are trivial if you only follow our explicit steps only. However once you enter a typical setup in a corporate environment where there is a central certificate authority issuing certificates, installing a certificate and private key for the Jetty SSL connector is commonly found difficult. Support questions often turn into a lesson about java keystores, certificates, how jetty works, how TLS works in general, what keytool commands to execute, installing and running openssl commands, etc.

      Further complicating this is the requirement that Docker registries by default require a secure connection in order to work. There is a UI for setting the port of these in NXRM, but without a global server TLS connector already setup, these docker specific connectors will not work.

      There are common problems encountered and many answers we have tried to document in articles in the support site. Despite this, we still get a lot of questions about all of it.

      Expected

      Provide a supported user interface that helps an admin user configure a global server SSL connector in repository manager. The interface should walk a user through things like

      • generating a private key
      • creating a CSR to give to their internal CA
      • installing a cert (and private key) from a thirdparty issued CA
      • automatically restarting NXRM or ideally, updating the keystore and installing the SSL connector dynamically without restart to apply the connector changes
      • persist the connector changes to the data directory so that the connector config survives upgrades
      • replacing an expired cert or existing cert on an already present connector
      • report errors and give opportunity for correction of invalid certs, like when
        • providing a cert that is not signed
        • providing a cert that is not signed by a known CA/root cert
        • providing a cert but no private key if the cert is provided by a 3rd party
        • handle converting/storing private keys into a keystore when the originating cert is in PKCS format ( keytool CLI does not have the ability to do this, requiring openssl )
      • handle PEM format certs and PKCS keystores
      • cert common name cannot resolve ( warn )

      The end result should be a dead simple way to get NXRM running a secure connector.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            plynch Peter Lynch
            Last Updated By:
            Rich Seddon Rich Seddon
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                tigCommentSecurity.panel-title