Documentation Nexus Repository Manager 3.0

Chapter 5. Security

Available in Nexus Repository OSS and Nexus Repository Pro

5.1. Introduction

Nexus Repository Manager Pro and Nexus Repository Manager OSS use role-based access control that gives administrators very fine-grained control over user rights to

  • read from a repository or a subset of repositories,
  • administer the repository manager or specific parts of the configuration,
  • access specific parts of the user interface,
  • deploy to repositories or even just specific sections of a repository.

The default configuration ships with roles and users with a standard set of permissions. As your security requirements evolve, you will likely need to customize security settings to create protected repositories for multiple departments or development groups. Nexus Repository Manager provides a security model that can adapt to any scenario.


The default administrator user give you full control and uses the username admin and the password admin123.

This chapter covers all aspects of security of the repository manager including

Security-related configuration can be performed with the feature views available via the Security section of the Administration main menu. Many of the features shown in this section are only available to users with the necessary privileges to access them.

The role-based access control system is backed by different authentication and authorizations systems as documented in Section 5.2, “Realms” and designed around the following security concepts:

Privileges are rights to read, update, create, or manage resources and perform operations related to the user interface as well as the components managed by the repository manager in the various repositories. The repository manager ships with a set of core privileges that cannot be modified.
Privileges can be grouped into collections called roles to make it easier to define privileges common to certain classes of users. For example, administrative users will all have similar sets of permissions. Instead of assigning individual privileges to individual users, you use roles to make it easier to manage users with similar sets of privileges.
Users can be assigned one or more roles, and model the individuals who will be logging into the user interface and read, deploy, or manage repositories as well as connect from client tools such at Apache Maven.

5.2. Realms

Available in Nexus Repository OSS and Nexus Repository Pro

The feature view for security realms administration displayed in Figure 5.1, “Security Realms Administration” allows you to activate and prioritize security realms used for authentication and authorization by adding them to the Active list on the right and placing them higher or lower on the list. It can be accessed via the Realms menu item in the Security submenu in the Administration main menu.


Figure 5.1. Security Realms Administration

Effectively, this configuration determines what authentication realm is used to grant a user access and the order the realms are used.

Nexus Authenticating Realm and Nexus Authorizing Realm
These are the built-in realms used by default. They allow the repository manager to manage security setup without additional external systems.
LDAP Realm
This realm identifies external storage in an LDAP system including e.g., Microsoft ActiveDirectory, ApacheDS, OpenLDAP with details documented in Section 5.7, “LDAP”.
Rut Auth Realm
This realm uses an external authentication in any system with the user authorization passed to the repository manager in a HTTP header field with details documented in Section 5.8, “Authentication via Remote User Token”.
NuGet API-Key Realm
This realm is required for deployments to nuget-format repositories as documented in Chapter 8, .NET Package Repositories with NuGet.

Removing all realms from the Active section prevents access to the repository manager for any user including any administrative access and has to be avoided.

5.3. Privileges

Available in Nexus Repository OSS and Nexus Repository Pro

Privileges control access to specific functionality of the repository manager and can be grouped as a role and assigned to a specific users.

To access Privileges go to the Security section, where it’s listed as a sub-section. An extensive list of privileges is already built in the repository manager and is partially depicted in Figure 5.2, “Partial List of Security Privileges”. This feature allows you inspect existing privileges and create custom privileges.


Figure 5.2. Partial List of Security Privileges

The list of privileges displays an icon for the privilege Type as the first column, followed by:

the internal identifier for the privilege
a human readable description of the purpose of the privilege
the aspect of the repository manager to which this privilege applies
the internal permission definition as used by the embedded security framework

Further details are available after pressing on a specific row in the detail view.

Click the Create privilege button to view a list of privilege types, as seen in Figure 5.3, “Choosing Privilege Types”.


Figure 5.3. Choosing Privilege Types

Select the privilege type corresponding to the area of the repository manager you wish to grant permissions. The privilege types are as follows:

These are privileges related to a defined aspect of the repository manager.
Repository Admin
These are privileges related to the administration and configuration of a specific repository.
Repository View
These are privileges controlling access to the content of a specific repository.
These are privileges related to the execution and management of scripts as documented in Chapter 15, REST and Integration API.
These are privileges that use patterns to group other privileges.

In all Privilege Types, above, the variables assigned to a role are defined as Actions. Actions can either be exclusive or a combination of add, browse, create, delete, edit, read and * (all) storage functions.

To save a new custom privilege click the Create privilege button. The privilege can be found listed among the default privileges on the main Privileges screen. You can use the Filter input box to find a specific privilege.

In the following example, an Application privilege type is created.


Figure 5.4. Creating an Application Privilege

The form provides Name, Description, Domain, and Actions. In Figure 5.4, “Creating an Application Privilege” the form is completed for a privilege only thats allows read access to the LDAP administration. If assigned this privilege, a user is able to view LDAP administration configuration but not edit it, create a new LDAP configuration, nor delete any existing LDAP configurations.

In another example, a Repository View privilege type is created.


Figure 5.5. Creating a Repository View Privilege

The form provides Name, Description, Format, Repository, and Actions. In Figure 5.5, “Creating a Repository View Privilege” the form is completed for a privilege granting sufficient access to publish images to a specific hosted repository. A user with this privilege can view and read the contents of the repository as well as publish new images to it, but not delete images.

5.4. Roles

Available in Nexus Repository OSS and Nexus Repository Pro

Roles aggregate privileges into a related context and can, in turn, be grouped to create more complex roles.

The repository manager ships with a predefined admin as well as an anonymous role. These can be inspected in the Roles feature view accessible via the Roles item in the Security section of the Administration main menu. A simple example is shown in Figure 5.6, “Viewing the List of Defined Roles”. The list displays the Name and Description of the role as well as the Source, which displays whether the role is internal (Nexus) or a mapping to an external source like LDAP.


Figure 5.6. Viewing the List of Defined Roles

To create a new role, click on the Create role button, select Nexus Role and fill out the Role creation feature view shown in Figure 5.7, “Creating a New Role”.


Figure 5.7. Creating a New Role

When creating a new role, you will need to supply a Role ID and a Name and optionally a Description. Roles are comprised of other roles and individual privileges. To assign a role or privilege to a role, drag and drop the desired privileges from the Available list to the Given list under the Privileges header. You can use the Filter input to narrow down the list of displayed privileges and the arrow buttons to add or remove privileges.

The same functionality is available under the Roles header to select among the Available roles and add them to the list of Contained roles.

Finally press the Create Role button to get the role created.

An existing role can be inspected and edited by clicking on the row in the list. This role-specific view allows you to delete the role with the Delete role button. The built-in roles are managed by the repository manager and cannot be edited or deleted. The Settings section displays the same section as the creation view as displayed in Figure 5.7, “Creating a New Role”.

In addition to creating an internal role, the Create role button allows you to create an External role mapping to an external authorization system configured in the repository manager such as LDAP. This is something you would do, if you want to grant every member of an externally managed group (such as an LDAP group) a number of privileges and roles in the repository manager.

For example, assume that you have a group in LDAP named scm and you want to make sure that everyone in the scm group has administrative privileges.

Select External Role Mapping and LDAP to see a list of roles managed by that external realm in a dialog. Pick the desired scm group and confirm by pressing Create mapping.


For faster access or if you cannot see your group name, you can also type in a portion or the whole name of the group and it will limit the dropdown to the selected text.

Once the external role has been selected, creates a linked role. You can then assign other roles and privileges to this new externally mapped role like you would do for any other role.

Any user that is part of the scm group in LDAP, receives all the privileges defined in the created role allowing you to adapt your generic role in LDAP to the repository manager-specific use cases you want these users to be allowed to perform.

5.5. Users

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager ships with two users: admin and anonymous. The admin user has all privileges and the anonymous user has read-only privileges. The default password for the admin user is admin123.

The Users feature view displayed in Figure 5.8, “Feature View with List of Users” can be accessed via the Users item in the Security section of the Administration menu. The list shows the users User ID, First Name, Last Name and Email as well as what security Realm is used and if the accounts Status is active or disabled.


Figure 5.8. Feature View with List of Users

Clicking on a user in the list or clicking on the Create user button displays the details view to edit or create the account shown in Figure 5.9, “Creating or Editing a User”. The ID can be defined upon initial creation and remains fixed thereafter. In addition you can specify the users First Name, Last Name and Email address. The Status allows you to set an account to be Disabled or Active.

The Roles control allows you to add and remove defined roles to the user and therefore control the privileges assigned to the user. A user can be assigned one or more roles that in turn can include references to other roles or to individual privileges.


Figure 5.9. Creating or Editing a User

The More button in the allows you to select the Change Password item in the drop down. The password can be changed in a dialog, provided the user is managed by the built-in security realm.


Ensure to change the password of the admin user to avoid security issues. Alternatively create other users with administrative rights and disable the default admin user.

5.6. Anonymous Access

Available in Nexus Repository OSS and Nexus Repository Pro

By default, the user interface as well as the repositories and the contained components are available to unauthenticated users for read access. The Anonymous feature view is available via the Anonymous item in the Security section of the Administration main menu and shown in Figure 5.10, “Configuring Anonymous Access”.

The privileges available to these users are controlled by the roles assigned to the anonymous user from the NexusAuthorizingRole. By changing the privileges assigned to this user in the Users feature view.


Figure 5.10. Configuring Anonymous Access

If you want to disable unauthenticated access to the repository manager entirely, you can uncheck the Allow anonymous users to access the server checkbox. The Username and Realm controls allow you to change the details for the anonymous user. E.g. you might have a guest account defined in your LDAP system and desire to use that user for anonymous access.

5.7. LDAP

Available in Nexus Repository OSS and Nexus Repository Pro

5.7.1. Introduction

Nexus Repository Manager Pro and Nexus Repository Manager OSS can use the Lightweight Directory Access Protocol (LDAP) for authentication via external systems providing LDAP support such as Microsoft Exchange/Active Directory, OpenLDAP, ApacheDS and others.

Configuring LDAP can be achieved in a few simple steps:

  • Enable LDAP Authentication Realm
  • Create LDAP server configuration with connections and user/group mapping details
  • Create external role mappings to adapt LDAP roles to repository manager specific usage

In addition to handling authentication, the repository manager can be configured to map roles to LDAP user groups. If a user is a member of a LDAP group that matches the ID of a role, the repository manager grants that user the matching role. In addition to this highly configurable user and group mapping capability, the repository manager can augment LDAP group membership with specific user-role mapping.

The repository manager can cache authentication information and supports multiple LDAP servers and user/group mappings. Connection details to the LDAP server and the user/group mappings as well as specific account logins can be tested directly from the user interface.

All these feature allow you to adapt to any specific LDAP usage scenario and take advantage of the central authentication set up across your organization in all your repository managers.

5.7.2. Enabling the LDAP Authentication Realm

As seen in Figure 5.1, “Security Realms Administration”, activate your LDAP Realm by following these steps:

  • Navigate to the Realms administration section
  • Select the LDAP Realm and add it to the list of Active realms on the right
  • Ensure that the LDAP Realm is located beneath the Nexus Authenticating Realm in the list
  • Press Save

Best practice is to leave the Nexus Authenticating Realm and the Nexus Authorizing Realm activated so that the repository manager can be used by anonymous, admin and other users configured in this realm even with LDAP authentication offline or unavailable. Any user account not found in the Nexus Authenticating Realm, will be passed through to LDAP authentication.

5.7.3. LDAP Connection and Authentication

The LDAP feature view displayed in Figure 5.11, “LDAP Feature View” is available via the LDAP item in the Security section of the Administration main menu.


Figure 5.11. LDAP Feature View

The Order determines in which order the repository manager connects to the LDAP servers when authenticating a user. The Name and URL columns identify the configuration and clicking on a individual row provides access to the Connection and User and group configuration.

The Create connection button can be used to create a new LDAP server configuration. Multiple configurations can be created and are accessible in the list.

The Change order button can be used to change the order in which the repository manager queries the LDAP servers in a pop up dialog.

Successful authentications are cached so that subsequent logins do not require a new query to the LDAP server each time. The Clear cache button can be used to remove these cached authentications.


Contact the administrator of your LDAP server to figure out the correct parameters, as they vary between different LDAP server vendors, versions and individual configurations performed by the administrators.

The following parameters allow you to create an LDAP connection:

Enter a unique name for the new configuration.
LDAP server address

Enter Protocol, Hostname, and Port of your LDAP server.

Valid values in this drop-down are ldap and ldaps that correspond to the Lightweight Directory Access Protocol and the Lightweight Directory Access Protocol over SSL.
The hostname or IP address of the LDAP server.
The port on which the LDAP server is listening. Port 389 is the default port for the ldap protocol, and port 636 is the default port for the ldaps.
Search base
The search base furhter qualifies the connection to the LDAP server. The search base usually corresponds to the domain name of an organization. For example, the search base could be dc=example,dc=com.

You can configure one of four authentication methods to be used when connecting to the LDAP Server with the Authentication method drop-down.

Simple Authentication
Simple authentication consists of a Username and Password. Simple authentication is not recommended for production deployments not using the secure ldaps protocol as it sends a clear-text password over the network.
Anonymous Authentication
The anonymous authentication uses the server address and search base without further authentication.
This is an improvement on the CRAM-MD5 authentication method. For more information, see RFC-2831.
The Challenge-Response Authentication Method (CRAM) is based on the HMAC-MD5 MAC algorithm. In this authentication method, the server sends a challenge string to the client. The client responds with a username followed by a Hex digest that the server compares to an expected value. For more information, see RFC-2195.

For a full discussion of LDAP authentication approaches, see RFC-2829 and RFC-2251.

SASL Realm
The Simple Authentication and Security Layer (SASL) realm used to connect to the LDAP server. It is only available if the authentication method is Digest-MD5 or CRAM-MD5.
Username or DN
Username or Distinguished Name DN of an LDAP user with read access to all necessary users and groups. It is used to connect to the LDAP server.
Password for the Username or DN configured above.

To test your connection to the external LDAP server, click Verify connection. A successful connection is confirmed with notification pop up.

The connection details can be further refined by configuring timeout period, retry period and number of connection attempts in Connection rules.

Click Next to proceed to configure user and group mappings for the LDAP configuration.

Figure 5.12, “Create LDAP Connection” shows a LDAP connection configuration for the repository manager configured to connect to an LDAP server running on localhost port 10389 using the search base of ou=system.


Figure 5.12. Create LDAP Connection

5.7.4. User and Group Mapping

The LDAP connection panel contains a section to manage User and group mappings. This configuration is the next step after you configure and verify the LDAP Connection. It is separate panel called Choose Users and Groups.

This panel provides a Configuration template drop-down, shown in Figure 5.13, “Configuration Template for Users and Groups”. Based on your template selection the rest of the field inputs will adjust to the appropriate user and group template requirements. These templates are suggestions for typical configurations used on servers such as Active Directory, Generic Ldap Server, Posix with Dynamic Groups and Posix with Static Groups. The values are suggestions only and have to be adjusted to your specific needs based on your LDAP server configuration.


Figure 5.13. Configuration Template for Users and Groups

The following parameters allow you to configure your user and group elements with the repository manager:

Base DN
Corresponds to the collection of distinguished names used as the base for user entries. This DN is relative to the Search Base. For example, if your users are all contained in ou=users,dc=sonatype,dc=com and you specified a Search Base of dc=sonatype,dc=com, you use a value of ou=users.
User subtree
Check the box if True. Uncheck if False. Values are True if there is a tree below the base DN that can contain user entries and False if all users are contain within the specified Base DN. For example, if all users are in ou=users,dc=sonatype,dc=com this field should be False. If users can appear in organizational units within organizational units such as ou=development,ou=users,dc=sonatype,dc=com, this field should be True.
Object class
This value is a standard object class defined in RFC-2798. and specifies the object class for users. Common values are inetOrgPerson, person, user or posixAccount.
User filter
This allows you to configure a filter to limit the search for user records. It can be used as a performance improvement.
User ID attribute
This is the attribute of the object class specified above, that supplies the identier for the user from the LDAP server. The repository manager uses this attribute as the User ID value.
Real name attribute
This is the attribute of the Object class that supplies the real name of the user. The repository manager uses this attribute when it needs to display the real name of a user similar to usage of the internal First name and Last name attributes.
Email attribute
This is the attribute of the Object class that supplies the email address of the user. The repository manager uses this attribute for the Email attribute of the user. It is used for email notifications of the user.
Password attribute
It can be used to configure the Object class, which supplies the password ("userPassword"). If this field is blank the user will be authenticated against a bind with the LDAP server. The password attribute is optional. When not configured authentication will occur as a bind to the LDAP server. Otherwise this is the attribute of the Object class that supplies the password of the user. The repository manager uses this attribute when it is authenticating a user against an LDAP server.

An automatically checked box will allow you to Map LDAP groups as roles. With the configuration any LDAP group configured for a specific users is used to query the roles in the repository manager. Identical names trigger the user to be granted the privileges of the roles.

Groups in LDAP systems are configured to be dynamic or static. A dynamic group is a list of groups to which users belong. A static group contains a list of users. Select Dynamic Groups or Static Groups from the Group type drop-down to proceed with the appropriate configuration.


Figure 5.14. Static Group Element Mapping

Static groups with an example displayed in Figure 5.14, “Static Group Element Mapping”, are configured with the following parameters:

Group base DN
This field is similar to the Base DN field described for User Element Mapping, but applies to groups instead of users. For example, if your groups were defined under ou=groups,dc=sonatype,dc=com, this field would have a value of ou=groups.
Group subtree
This field is similar to the User subtree field described for User Element Mapping, but configures groups instead of users. If all groups are defined under the entry defined in Base DN, set the field to false. If a group can be defined in a tree of organizational units under the Base DN, set the field to true.
Group object class
This value in this field is a standard object class defined in RFC-2307. The class is simply a collection of references to unique entries in an LDAP directory and can be used to associate user entries with a group. Examples are groupOfUniqueNames, posixGroup or custom values.
Group ID attribute
Specifies the attribute of the object class that specifies the group identifier. If the value of this field corresponds to the ID of a role, members of this group will have the corresponding privileges.
Group member attribute
Specifies the attribute of the object class which specifies a member of a group. An example value is uniqueMember.
Group member format
This field captures the format of the Group Member Attribute, and is used by the repository manager to extract a username from this attribute. An example values is ${dn}.

If your installation does not use static groups, you can configure the LDAP connection to refer to an attribute on the user entry to derive group membership. To do this, select Dynamic Groups in the Group type drop down.


Figure 5.15. Dynamic Group Element Mapping

Dynamic groups are configured via the Group member of attribute parameter. The repository manager inspects this attribute of the user entry to get a list of groups of which the user is a member. In this configuration, seen in Figure 5.15, “Dynamic Group Element Mapping”, a user entry would have an attribute that would contain the name of a group, such as memberOf.

Once you have configured the user and group settings on the Choose Users and Groups form, you can check the correctness of your user mapping by pressing the Verify user mapping button. A successful mapping will result in the retrieval of a list of user records, which will be shown in the User Mapping Test Result dialog.

The repository manager provides you with the ability to test a user login directly. To test a user login, go to the Choose Users and Groups page after all appropriate field inputs of the form are filled. Scroll to the bottom and click the Verify login button.

The Verify login button can be used to check if authentication and user/group mappings work as expected for a specific user account besides the global account used for the LDAP configuration.

After your LDAP the successful configuration of your connection and user and group mappings, you can proceed to configure external role mappings. This allows you to define the repository manager specific security for a LDAP group. More details are available in Section 5.4, “Roles”.

5.8. Authentication via Remote User Token

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager allows integration with external security systems that can pass along authentication of a user via the Remote_User HTTP header field for all requests - Remote User Token Rut authentication. This typically affects all web application usage in a web browser.

These are either web-based container or server-level authentication systems like Shibboleth. In many cases, this is achieved via a server like Apache HTTPD or nginx proxying the repository manager. These servers can in turn defer to other authentication storage systems e.g., via the Kerberos network authentication protocol. These systems and setups can be described as Central Authentication Systems CAS or Single Sign On SSO.

From the users perspective, he/she is required to login into the environment in a central login page that then propagates the login status via HTTP headers. the repository manager simply receives the fact that a specific user is logged in by receiving the username in a HTTP header field.

The HTTP header integration can be activated by adding and enabling the Rut Auth capability as documented in Section 4.2.2, “Accessing and Configuring Capabilities” and setting the HTTP Header name to the header populated by your security system. Typically, this value is REMOTE_USER, but any arbitrary value can be set. An enabled capability automatically causes the Rut Auth Realm to be added to the Active realms in the Realms configuration described in Section 5.2, “Realms”.

When an external system passes a value through the header, authentication will be granted and the value will be used as the user name for configured authorization scheme. For example, on a default installation with the internal authorization scheme enabled, a value of admin would grant the user the access rights in the user interface as the admin user.

A seamless integration can be set up for users if the external security system is exposed via LDAP and configured in the repository manager as LDAP authorization realm combined with external role mappings and in parallel the sign-on is integrated with the operating system sign-on for the user.

5.9. Configuring SSL

Using Secure Socket Layer (SSL) communication with the repository manager is an important security feature and a recommended best practice. Secure communication can be inbound or outbound.

Outbound client communication may include integration with

Inbound client communication includes

  • web browser HTTPS access to the user interface,
  • tool access to repository content,
  • and manual or scripted usage of the REST APIs.

5.9.1. Outbound SSL - Trusting SSL Certificates of Remote Repositories

Available in Nexus Repository OSS and Nexus Repository Pro

When the SSL certificate of a remote proxy repository is not trusted, the repository may be automatically blocked or outbound requests fail with a message similar to PKIX path building failed.

The Proxy configuration for each proxy repository documented in Section 4.3.5, “Managing Repositories and Repository Groups” includes a section titled Use the Nexus truststore. It allows you to manage the SSL certificate of the remote repository and solves these problems. It is only displayed, if the remote storage uses a HTTPS URL.

The View certificate button triggers the display of the SSL Certificate Details dialog. An example is shown in Figure 5.16, “Certificate Details Dialog to Add an SSL to the Nexus Truststore”.


Figure 5.16. Certificate Details Dialog to Add an SSL to the Nexus Truststore

Use the Certificate Details dialog when the remote certificate is not issued by a well-known public certificate authority included in the default Java trust store. This specifically also includes usage of self-signed certificates used in your organization. To confirm trust of the remote certificate, click the Add certificate to truststore button in the dialog. This feature is analogous to going to the SSL Certificates user interface and using the Load certificate button found there as described in Section 5.9.2, “Outbound SSL - Trusting SSL Certificates Globally”. If the certificate is already added, the button can undo this operation and will read Remove certificate from trust store.

The checkbox labelled Use certificates stored in Nexus to connect to external systems is used to confirm that the repository manager should consult the internal truststore as well as the JVM truststore when confirming trust of the remote repository certificate. Without adding the certificate to the private truststore and enabling the checkbox, the repository will not trust the remote.

The default JVM truststore of the JVM installation used to run the repository manager and the private truststores are merged. The result of this merge is used to decide about the trust of the remote server. The default Java truststore already contains public certificate authority trust certificates. If the remote certificate is signed by one of these authorities, then explicitly trusting the remote certificate will not be needed.


When removing a remote trusted certificate from the truststore, a repository manager restart is required before a repository may become untrusted.

5.9.2. Outbound SSL - Trusting SSL Certificates Globally

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager allows you to manage trust of all remote SSL certificates in a centralized user interface. Use this interface when you wish to examine all the currently trusted certificates for remote repositories, or manage certificates from secure remotes that are not repositories.

Access the feature view for SSL Certificates administration by selecting the SSL Certificates menu items in the Security submenu in the Administration main menu.


Figure 5.17. SSL Certificates Administration

The list shows any certificates that are already trusted. Clicking on an individual row allows you to inspect the certificate. This detail view shows further information about the certificate including Subject, Issuer and Certificate details. The Delete certificate button allows you to remove a certificate from the truststore.

The button Load certificate above the list of certificates can be used to add a new certificate to the truststore by loading it directly from a server or using a PEM file representing the certificate.

The common approach is to choose Load from server and enter the full https:// URL of the remote site, e.g, The repository manager will connect using HTTPS and use the HTTP proxy server settings if applicable. When the remote is not accessible using https://, only enter the host name or IP address, optionally followed by colon and the port number. For example: . In this case the repository manager will attempt a direct SSL socket connection to the remote host at the specified port. This allows you to load certificates from SMTP or LDAP servers, if you use the correct port.

Alternatively you can choose the Paste PEM option to configure trust of a remote certificate. Copy and paste the Base64 encoded X.509 DER certificate to trust. This text must be enclosed between lines containing -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- .

Typically this file is supplied to you by the certificate owner. An example method to get the encoded X.509 certificate into a file on the command line using keytool is:

keytool -printcert -rfc -sslserver > repo1.pem

The resulting repo1.pem file contains the encoded certificate text that you can cut and paste into the dialog in the user interface. An example of inserting such a certificate is shown in Figure 5.18, “Providing a Certificate in PEM Format”.


Figure 5.18. Providing a Certificate in PEM Format

If the repository manager can successfully retrieve the remote certificate or decode the pasted certificate, the details will be shown allowing you to confirm details as shown in Figure 5.19, “Certificate Details Displayed after Successful Retrieval or Parsing”. Please review the displayed information carefully before clicking Add Certificate to establish the truststore addition.


Figure 5.19. Certificate Details Displayed after Successful Retrieval or Parsing

In some organizations, all of the remote sites are accessed through a globally configured proxy server which rewrites every SSL certificate. This single proxy server is acting as a private certificate authority. In this case, you can follow special instructions for trusting the proxy server root certificate, which can greatly simplify your certificate management duties.

5.9.3. Outbound SSL - Trusting SSL Certificates Using Keytool

Available in Nexus Repository OSS and Nexus Repository Pro

Managing trusted SSL certificates from the command line using keytool and system properties is an alternative and more complex option than using the SSL certificate management features of the repository manager.

Before you begin the process of trusting a certificate from the command line you will need:

If you are connecting to servers that have certificates which are not signed by a public CA, you will need to complete these steps:

  1. Copy the default JVM truststore file ($JAVA_HOME/jre/lib/security/cacerts) to a specific location for editing.
  2. Import additional trusted certificates into the copied truststore file.
  3. Configure JSSE system properties for the repository manager process so that the custom truststore is consulted instead of the default file.

Some common commands to manually trust remote certificates can be found in our SSL Certificate Guide.

After you have imported your trusted certificates into a truststore file, you can add the JVM parameters configuring the truststore file location and password as separate configuration lines into the file etc/<truststore><truststore_password>

Once you have added the properties shown above, restart the repository manager and attempt to proxy a remote repository using the imported certificate. The repository manager will automatically register the certificates in the truststore file as trusted.

5.9.4. Inbound SSL - Configuring to Serve Content via HTTPS

Available in Nexus Repository OSS and Nexus Repository Pro

Providing access to the user interface and content via HTTPS is a best practice.

You have two options:

  • Using a separate reverse proxy server in front of the repository manager to manage HTTPS
  • Configure the repository manager itself to serve HTTPS directly

Using A Reverse Proxy Server

A common approach is to access the repository manager through a dedicated server which answers HTTPS requests on behalf of the repository manager - these servers are called reverse proxies or SSL/TLS terminators. Subsequently requests are forwarded to the repository manager via HTTP and responses received via HTTP are then sent back to the requestor via HTTPS.

There are a few advantages to using these which can be discussed with your networking team. For example, the repository manager can be upgraded/installed without the need to work with a custom JVM keystore. The reverse proxy could already be in place for other systems in your network. Common reverse proxy choices are Apache httpd, nginx, Eclipse Jetty or even dedicated hardware appliances. All of them can be configured to serve SSL content, and there is a large amount of reference material available online.

Serving SSL Directly. The second approach is to use the Eclipse Jetty instance that is distributed with the repository manager to accept HTTPS connections.

How to Enable the HTTPS Connector

  1. Create a Java keystore file at $install-dir/etc/ssl/keystore.jks which contains the Jetty SSL certificate to use. Instructions are available on the Eclipse Jetty documentation site.
  2. Edit $install-dir/etc/ Add a property on a new line application-port-ssl=8443. Change 8443 to be your preferred port on which to expose the HTTPS connector.
  3. Edit $install-dir/etc/ Change the nexus-args property comma delimited value to include ${karaf.etc}/jetty-https.xml. Save the file.
  4. Restart Nexus. Verify HTTPS connections can be established.
  5. Update the Base URL to use https in your repository manager configuration using the Base URL capability.

This configuration process is available as a video demonstration.

How to Redirect All Plain HTTP Requests to HTTPS

Some organizations need to remind their users that Nexus should only be used over HTTPS - redirecting HTTP requests to HTTPS can help.

  1. Follow all the steps under How to Enable the HTTPS Connector. Make sure the nexus-args property value still includes the reference to ${karaf.etc}/jetty-http.xml
  2. Edit $install-dir/etc/ Change the nexus-args property comma delimited value to include ${karaf.etc}/jetty-http-redirect-to-https.xml. Save the file.
  3. Restart Nexus. Verify all plain HTTP requests get redirected to the equivalent HTTPS url.

Redirecting HTTP requests is not recommended because it introduces implied security and creates increased network latency. Clients which send Basic Authorization headers preemptively may unintentionally expose credentials in plain text.

How to Disable the HTTP Connector

  1. Edit $install-dir/etc/ Change the nexus-args property comma delimited value to not include ${karaf.etc}/jetty-http.xml. Save the file.
  2. Restart Nexus. Verify plain HTTP requests are no longer serviced.