Operations

Vendor Operations

Vendor portal URL: the Vendor Portal can use the same SSLNexus origin or a dedicated public hostname. For separated deployments, keep the full/admin listener private and publish only the vendor-only listener, for example https://vendors.example.org/vendor/. The Vendors page shows the configured public URL.

Delegated Request Workflow

The vendor portal gives approved external or delegated users a controlled way to request certificate work without granting access to the main SSLNexus administration interface.

Onboard A Vendor

Create the vendor organisation, assign the domains or scope it is permitted to request, and invite the appropriate vendor users. Keep vendor access separate from administrator access.

Vendor Security Boundaries

Vendor Portal access is constrained independently at the identity, network and certificate-request layers. Use all three where practical rather than treating the vendor login as the only control.

Private-key non-retention: vendor-generated key material is shown for one-time collection and is not retained by SSLNexus. The portal requires vendor RSA keys of at least 4096 bits.
Source-network restriction: assign the approved source IP address or CIDR ranges for the vendor so requests from outside the expected corporate or service network are rejected.
Delegated certificate scope: assign only the certificate names the vendor is responsible for. Common names and SANs must remain inside that delegated scope; an out-of-scope request is rejected before issuance.

Recommended: combine named vendor identities or SSO, source-network restrictions and delegated certificate scope. A leaked credential should not, by itself, provide unrestricted certificate-request capability.

Certificate Requests

Vendor users select the delegated common name, edit the SAN list within that delegated scope, choose an RSA key size starting at 4096 bits, and generate their one-time CSR/private key in the portal. 2048-bit vendor CSRs are not accepted. When the request passes the source-network, renewal-window and request-rate controls, SSLNexus sends it directly to the CA adapter assigned by the organisation. There is no administrator approval queue for Vendor Portal issuance.

The portal tracks issuance progress and automatically displays the returned certificate for copy or download when the CA completes the request.

One Active Certificate Per Name

SSLNexus allows only one active, valid vendor-issued certificate for an approved certificate name within the organisation. If a valid certificate already exists, the vendor must revoke it from Certificate history before another can be requested. Expired certificates do not block a replacement. Revoked and expired certificates remain visible and downloadable for historical reference.

The rule is enforced server-side and applies in addition to the configured vendor request rate limit.

Vendor Support Tickets

Signed-in vendors can open Support in the Vendor Portal and create a threaded ticket for the organisation administrators. Opening a ticket emails every enabled Administrator using the configured notification transport. Administrators and Operators reply, resolve, or reopen tickets from Vendor access → Vendor support tickets.

Monitor Delegated Issuance

Administrators and Operators monitor vendor requests, certificate status and renewal position from the main interface. The organisation remains in control of CA connectivity, the approved certificate name, source-network policy and request limits without becoming a manual approval bottleneck.

Certificate Handoff Lifecycle

Certificate issuance and vendor handoff are tracked separately. Once issuance succeeds, the normal self-service handoff moves through Issued → Retrieved → Installed → Verified → Complete. A separate vendor-notified marker remains available for manual operational handoffs where teams choose to use it.

Retrieved is recorded automatically when the vendor views or downloads the issued certificate.
Installed is confirmed by the vendor in the Vendor Portal.
Verified and Complete are recorded by an Operator or Administrator after checking the installation.

Handoffs left in an actionable stage for more than 24 hours are highlighted as needing attention. Staff can send a reminder to the assigned vendor using the configured notification transport. Reminder counts and lifecycle timestamps are retained in Activity & audit.

Separate Public Vendor Portal Hostname

Enterprise deployments can publish the Vendor Portal on its own hostname without exposing the administrator interface. SSLNexus keeps the vendor application backend on a loopback listener and manages the public Nginx/TLS edge locally.

DNS And Firewall Prerequisites

Create an A and/or AAAA record for the Vendor Portal hostname, for example vendors.example.org.
Point that record directly to the same server that runs SSLNexus. The DNS check also accepts a public NAT address when the configured SSLNexus control-plane hostname resolves to that same address.
Allow public TCP 80 and 443 to reach Nginx on the SSLNexus server. Port 80 is required for Let's Encrypt HTTP-01 validation.
Keep the Vendor Portal backend listener on loopback, such as 127.0.0.1:8081. Do not expose that backend port directly to the Internet.

DNS proxy/CDN note: the hostname must resolve to the SSLNexus server during the built-in validation. If a proxy service returns its own addresses instead, disable proxying for initial setup or use direct DNS.

Configure The Endpoint

Open Settings → Vendor portal.
Enter the public URL, for example https://vendors.example.org.
Enter the loopback Vendor-only backend listener, for example 127.0.0.1:8081.
Enter the Let's Encrypt account email, or leave it blank when a global Let's Encrypt account email is already configured.
Select Validate DNS and save.

SSLNexus resolves the hostname and confirms that it belongs to this server before provisioning continues. It then creates the public Nginx HTTP/HTTPS frontend, reserves /.well-known/acme-challenge/, requests the Vendor Portal certificate from Let's Encrypt, validates the Nginx configuration and reloads Nginx. You do not need to add certificate directives manually.

The public listener exposes only Vendor Portal routes, vendor session/API routes, required assets, vendor documentation and health checks. Requests for /admin/ or /api/admin/* are not available through the vendor-only application listener.

The Vendor Portal certificate is checked daily and renewed automatically when it approaches expiry. If vendor SSO is enabled, configure the Vendor redirect URL as https://vendors.example.org/api/session/oidc/callback and register that callback with the identity provider.

Vendor Workspace

After sign-in, the landing page stays focused on certificate generation and issuance. A compact left navigation rail holds Certificate history, Support and vendor-specific Documentation, keeping historical and support activity away from the primary task.

Ticket Isolation

Vendor support tickets are scoped by both organisation and vendor identity. A vendor cannot list, read or reply to another vendor's tickets, even inside the same organisation. Administrator replies remain inside the selected ticket thread and are not broadcast to other vendors. Only the administrator notification generated when a ticket is opened is fanned out to enabled administrators in that organisation.

Offboarding

Disable vendor access when the relationship ends or when a user no longer requires access. Existing certificate records remain available to administrators.