TLS, Reverse Proxies, Context Paths, HTTP Settings, Network Boundaries, and Secure Exposure: Configuration, Design Choices, and Tradeoffs

1. Architecture is a set of explicit choices

The Chapter 17 lab used one host, TLS termination, a root context, and one Raw repository. Production introduces more dimensions: where TLS ends, how many hostnames are exposed, whether package and administration traffic share a plane, whether clients tolerate a context path, how registry routes are expressed, and who owns certificate rotation.

2. TLS at the edge versus end-to-end TLS

Sonatype supports serving HTTPS directly but recommends reverse-proxy SSL management as a common production approach. The correct choice is driven by network trust boundaries and operational ownership, not by a belief that two TLS layers are automatically “more secure.”

3. One hostname versus per-format hostnames

A single name such as repo.example.invalid simplifies certificates, DNS, and developer onboarding. Per-format names such as maven.repo.example.invalid or containers.repo.example.invalid can make traffic policy and client configuration clearer, but enlarge DNS/certificate/routing state.

4. Paths, ports, and subdomains are client-protocol choices

Most repository formats work naturally through Nexus repository paths. OCI/Docker needs special treatment because registry clients expect a /v2/ API and specific authentication challenges. Current OCI configuration supports path-based routing in all deployments, port routing on self-hosted deployments, and subdomain routing only with Pro entitlement.

Port connectors are valid but each consumes server resources and introduces firewall/listener management. Sonatype recommends limiting Docker port connectors and prefers reverse-proxy SSL management. Do not create a new connector for every repository simply because it was historically common.

5. Package plane versus administration plane

Developers and CI need repository endpoints; repository administrators need the UI and security/administrative APIs. Those audiences do not automatically need the same network exposure. A production edge can expose package paths broadly to an authenticated workforce or build network while permitting administration only from a VPN, bastion, privileged subnet, or dedicated internal hostname.

flowchart LR
DEV[Developers / CI] --> PUB[Package edge policy]
ADM[Administrators] --> VPN[Private admin edge]
PUB --> N[Nexus private listener]
VPN --> N
N --> DB[(Database)]
N --> BS[(Blob stores)]

The two edge paths converge on one Nexus authorization model, database, and blob store. Network segmentation narrows who can reach an interface; Nexus roles/privileges still decide what an authenticated principal can do.

6. Root path versus custom context path

A root context (/) has the lowest client compatibility risk. A custom context such as /nexus can fit shared-domain conventions, but it becomes part of every UI, REST, webhook, package, and SSO URL. Current Sonatype docs explicitly require setting nexus-context-path in Nexus and forwarding the same context path for SSO.

7. Certificate automation versus manual rotation

Manual renewal can be acceptable for a short-lived local lab. Production certificates should have an owner, expiration monitoring, a renewal mechanism, deployment automation, and a rollback plan. The safe rotation sequence is issue new certificate → validate SAN/chain/key match → deploy at one edge → perform TLS and package-client smoke tests → roll out → remove the old certificate only after successful validation.

Do not treat “certificate successfully installed” as sufficient. A client can reject the certificate because of trust-chain, SAN, SNI, expiration, clock, or endpoint mismatch even when the proxy process starts normally.

8. Base URL, context path, and forwarded headers solve different problems

9. Worked scenario: 120 developers, CI, containers, private administrators

Assume Maven/npm/PyPI clients, one OCI group, internet-facing remote workers over corporate access, and five repository administrators. The team wants minimal certificates and no direct backend exposure.

10. Keep adjacent systems in their own ownership domains

• Nexus owns repository configuration, runtime listener/context, roles, capabilities, and repository data.
• The reverse proxy owns edge certificates, external listeners, forwarded headers, request-size/time-out policy, and routing.
• DNS and firewalls own name resolution and network reachability.
• Package managers own client trust, local cache, registry/feed URL, and credentials.
• Identity providers and CI systems own their own sessions/tokens/secrets; Nexus consumes the resulting authentication path.

11. Knowledge check

12. Summary and next step

A production network topology is a tradeoff among client compatibility, certificate ownership, network trust, operational complexity, and recoverability. Lesson 4 turns those tradeoffs into a diagnostic method so transport failures are not misdiagnosed as repository or credential problems.

Official references and version notes

• Sonatype: Run Behind a Reverse Proxy — recommended reverse-proxy patterns and custom-context handling.
• Sonatype: Configure OCI Repository — current path/subdomain/port routing availability and OCI bearer realm.
• Sonatype: Docker Registry — connector resource and reverse-proxy SSL guidance.
• Sonatype: Download Archives — documented 3.92.0 custom context-path issue fixed in 3.92.1.